Logged In: YES 
user_id=21627

I thought the problem with memory blocks still exists: If
you malloc with the debug CRT, and free with the nodebug
CRT, you get a leak. At least Q140584 claims the problem
still exists in 6.0sp5. In addition to memory and files,
they also notice that setting the locale in one CRT doesn't
affect the other.

I still cannot tell whether Anonymous builds a DLL wrapper
or a static library around pythonxy.dll.If it was a DLL, it
would be indeed equivalent to the pyexpat case. However, in
that case, linking Python wouldn't matter at all to the
clients of his or her DLL, since the reference to
pythonxy.dll/pythonxy_d.dll would be only in the wrapper DLL.

Re: decoupling _DEBUG and Py_DEBUG. How exactly would that
work? Would a _d extension imply _DEBUG, or Py_DEBUG, or
would we stop using _d? 

If it would imply _DEBUG, I cannot understand Mark's comment
"Individual extensions would be responsible for setting
Py_DEBUG via their makefiles in debug builds.  This should
be stable." You have to use Py_DEBUG consistently throughout
all modules because it changes the struct _object layout.
Mixing them certainly isn't stable.

Perhaps we could try to completely avoid changing
PyObject_HEAD depending on Py_TRACE_REFS, and make it a type
flag instead. In that case, you could, at run-time, mix
objects that do trace_refs, and objects that don't.