Destructors are usually hard to support cleanly in the presence of obligate GC. Given destructors, GC turns out to be unnecessary. Lacking destructors, managing non-memory resources becomes foolishly difficult, particularly across library boundaries.
OK then! I will be interested to see how destructors are reconciled with GC.
Where I have seen GC used in C++ runtimes, it is confined to specific, graph-like structures, where tracking cycles would be messy; or provided to obligate-GC languages being interpreted. In both cases it is always clear whether an object's lifetime is tracked, and the C++ runtime does not see the objects.
I know there are problems with destructors. That's why I didn't implement them yet. But in C# they do exist. And after all you may always use explicit finalizers. I don't think that it makes the concept of obligate-GC invalid.
But after all I don't care much. I'm more interested in other parts of language designs :)