FWIW, I _do_ use DLLs in packages, and it causes me no end of grief. I need to have special runtime hacks that works with __path__, I need a special __init__ in the package where the DLL is to "appear", and also need even further special casing for Freeze! So although I can see the problems with the mechanisms, IMO it is very important that packages be capable of treating DLLs as first-class citizens. Personally, I would not have a "compatibility" problem as such, but I would need to remove or update my hacks - but I find that reasonable. Mark.
Backwards compatible with what? Currently builtin modules can't be in packages at all, so nothing's lost.
But DLLs *can* be (that's the whole point, no?). If the rules for the init func changes, I think at least Marc-Andre L. won't be too happy: all (?) of his extensions use DLLs as submodules, so he would need to add switches to remain compatible with 1.5.2. I'm sure he's not the only one.