Side-effect of deprecation of MBCS support for MFC in VS 2013

I just tried to compile an old MFC app under VS2013. It complained that non-Unicode MFC applications were deprecated, and refused to compile. Which is somewhat contrary to this announcement that talks about deprecating support for MBCS. Until now there were three choices for the Character Set option:

• Unicode
• MBCS
• Not set

Personally, I'm entirely comfortable with dropping support for MBCS - I neither want nor need MBCS. But nor do I want nor need Unicode - ANSI/ASCII is just fine by me. So insisting that every MFC application henceforth must speak Unicode, and (in effect) provide the foundations of a platform support all possible languages, no matter who its intended audience is, seems... extreme. Am I missing something? Should I still be able to compile an MFC application with no character set specified under VS2013?

You can. Currently all my programs use the Unicode library. Except one older one, that includes very old code from previous versions and this program is needed for update support for this od version...

1. Currently there is an Addon that still supports MBCs.
2. Vote for it
3. As I understand the discussion (see comment of Mark Davis dated December 2014) such an Addon will be available up and including VS2015 (whatever Version is meant).

To be more precise what happens when you select "None" for the character set:

1. You program is linked against the MBCS Version of the MFC
2. Also the Windows SDK will Default to the MBCS Version of the API. So i.e. GetWindowTextA is calls instead of GetWindowTextW

So in fact. Setting _UNICODE and _MBCS to nothing just Defaults to _MBCS...

Internally the SDQ always checks a if UNICODE (not _UNICODE) is set. If not the MBCS Version is chosen.