This is essentially the differences between strSafe and Safe CRT
Headers: One (StrSafe.h) vs. Numerous (various C runtime headers)
Library Version Available: Yes on both cases
Inline Version Available: Yes for StrSafe
Industry Standard: Possibly for the Safe CRT. Depends on the end result of the C Library TR 24731-1 (pdf link). Personally I suspect not.
Kernel Mode: Yes for the StrSafe.
Objectives: Buffer overruns for the SafeStr and Buffer overruns plus anything else for the Safe CRT.
Meanwhile both options overlap in many of the banned APIs which should give you some freedom of choice. To choose one over the other is a matter of looking at what they offer from the list above (also available, and more complete, at the Ban list address). Not anything else.
But essentially, the Safe CRT option (the one you see on any VC++ 2005 and 2008 versions and that annoys you with those "deprecated warnings) doesn't include any special magic either. None of the appointed replacements are full-proof solutions. None of them plan to be.
There's however a few issues they are fixing for the next version, 5.0. For instance, strlen and friends presence there (table 19) doesn't make any sense unless it is meant for sensitive server operations under anonymous connections (to avoid non-terminating string attacks for instance). As such, these functions are planned to be removed entirely from the banned list.
Look, IMHO the thing is twofold:
1. You have a clear problem of language. Words like "Banned", "Deprecated" and "Safe" are terrible choices. This is bringing a lot of confusion to anyone who, rightfully so, doesn't want to dig deeper into all this crap. Words like these are very powerful and have a very specific meaning in the context of software development. However they are being used rather irresponsibly by Microsoft itself. At least that's my opinion. First because only in the context of the SDL are these functions "Banned". Second because a compiler doesn't "Deprecate" a standard. Third because the solutions aren't "Safe".
2. Not without fundamental changes to how C++ compiles would it ever be possible to create fully full-proof versions of these functions. This is most probably never going to happen. These solutions are to be understood once and for all in this context. They aren't safe. They are safer. And they are safer simply because on the majority of cases they introduce the element of size in the function signature, forcing the programmer to give it a thought. Not because of any new compilation magic. Within the context of the SDL however that's an entirely different matter. Supported by these functions and the Process Template parameters and definitions, you have the tools to then run all sorts of code analysis tests to guarantee your code safety. That's where these functions may trully shine. But that doesn't mean errors won't still creep in. Processes aren't always respected, reports aren't always read or correctly interpreted, schedules are often tight and it's the Testing phase that usually gets swollen up, people will keep making mistakes. One can expect to reduce the problems. Not solve them.
When I started following this a little more close in the beginning of the year, this issue became quite apparent to me just from reading some of the replies on some of the Microsoft representatives blogs. When you have programmers asking if the size parameter includes the target buffer null terminator, it just becomes crystal clear not only the solutions aren't meant to solve the problem (instead, to minimize it), but also anyone who makes these type of question really needs to use these functions.