Yes, the CRT allocates from the default process heap since VS2012. The one returned by GetProcessHeap(). Primary motivation for that change was probably not the improved module interop, VS2012 initially shipped without support for XP so there was no longer any need to create a private heap and call HeapSetInformation() to turn on the low-fragmentation heap. Vista and up have it enabled by default.
That didn't last, a storm of protests forced them to put XP support back. Without otherwise changing the code, I have never seen anybody complain about that. Makes you wonder if perceived need to support an ancient OS does in fact match actual need.
It doesn't otherwise do anything to solve the other problems caused by having multiple copies of the CRT in a process. Like /MT vs /MTd, your case, the debug build of the CRT adds extra metadata to an allocated memory block to detect heap corruption and bad pointer usage. That is missing from a block allocated by the non-debug CRT. So kaboom when you pass that pointer to a free() or ::operator delete call in the debug CRT, it can't find the metadata back.
And the range of other issues caused by global state in the CRT. Like errno, setlocale(), strtok(), strerror(), asctime(), gmtime(), etcetera.
So basic advice does not change, only use /MT for simple single module programs (just an EXE, no DLLs) or DLLs with a very carefully designed interface.