people are going to add things into their modules to make whatever software they need. If I find that I need libfoo2-2.34 in libreoffice and you need libfoo2-2.40 in evolution.. then only one of the two modules can be installed.You can either have libreoffice or you can have evolution.
Cap't Obvious here, but I think the logic is like this:
The logical conundrum of modularity is that when we require non-default modules, then it logically follows that there will be conflicts (if there weren't, we wouldn't need modules) and so we are forced all the way into 4. unless we're lucky, and happen not to need the packages that depend on conflicting modules.
The bottom line is that modularity is useful, but in the sense of insurance or fire extinguishers: it's good to have them but we should really hope that we won't have to use them.
If only there was a way to limit the scope of the non-default
modules to their dependencies--by using private library
directories or something like that? I think it would solve the
problem of parallel installation, and would simplify upgrades by
making it explicit what pulled them in in the first place, and
place joint responsibility for updates on these subsystems. This
is essentially bundling, but exposed in the packaging system so
it's more manageable.