I still prefer my solution.
Ok, but please consider that it will then become
somewhat more difficult to add an alternative layout subsystem.
Layout subsystems are much rarer than people think, so not that much a concern IMO. Keyword here is "somewhat more difficult"--it's not insurmountable--and compared to the vast complexity of creating a layout subsystem--almost noise level. It will be a few more headaches, but you'll have a better LS in HEAD to base your code off of as a result.
IMHO the closer integrated FO tree and LM tree classes is a worse starting point. Victor had the right intentions on this.
[...]. I'm seeing the increase in patches to FOP that will result in this change as a greater benefit*, because (1) only the severe minority of FOP users create their own layout strategies while the majority benefits from a faster-created 1.0, and (2) more patches give alternative LS people more and better code for them to base their work on, and in some cases may even remove the need to have an alternative LS at all.
You seems to assume that the one default layout system in FOP can satisfy all requirements. I doubt that. The default layout system should be good but it shouldn't try solve everything perfectly IMO. Perhaps Jörg disagree <wink>.
*You are a good example, because if it's more difficult for you to create an "alternative", you'll be more likely to come back to FOP and start making improvements to HEAD's layout strategy! GOOD! (Please do!) I would rather you work on FOP than on a competitor for it.
My alternative layout subsystem isn't an alternative to FOP but an alternative way of implementing the getNextBreakPoss() code.
I do not yet know if anything will come of it but it looks quite promising. If it works, I'll post it as a patch for discussion.