libpd requires a lot of what pd-l2ork offers in order to be able to move forward (obeying stacking order for instance, that are a prerequisite for global system-wide presets as well as editing tools like undo/redo and tofront/back).
Those sound like things that should/could be in the core.
pd-l2ork also improves on pack, route, select, and trigger to make things easier for newcomers to understand and for professionals to get to their results faster. None of these are a part of the core and yet they very much belong to libpd...
Those are objects and they can simply alias the existing objects on load, that or add an option to the core to not load existing objects / allow conditional calls the the object setup functions.
I simply don't see fragmentation as a bad thing. Look at Linux--fragmentation galore. And yet we all get along just fine (well for the most part ;-)
The kernel is fragmented? Your talking distros and I see things going more Linux & BSD.
If it will make it any easier for you, refer to pd-l2ork as anchovies and forget for a moment that it has any compatibility with pd whatsoever. This could ostensibly become a reality in not so distant future from now (well the compatibility part, not so sure about the name).
I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals.
That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility.
Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying.
Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ...
If the reality is as you say, then I'm not really interested in spending my time hacking on our little island.