Hmmm...not that big a deal to me, but I would be inclined to keep the whitespace removal out of the LayoutManagers, because it is fo:block specific
I don't quite understand this argument. Handling space-before is also
fo:block specific. Where should this logic be put, then?
If you replace "whitespace handling" with "replacing every occurrence of the letter 'A' with 'B'", a similar idea, you can see what I'm getting at--the fo:block should be able to clean itself up (if there is such a property defined for the fo mandating that cleanup) prior to presenting itself to layout, so layout needn't be concerned with the "whitespace handling". The earlier this is done, preferably in flow.Block, the less work (and fewer instantiations) for FOText object and TextLayoutManager.
It is fo:block specific in the sense that not all fo:blocks mandate it.
The analogy with space-before is imperfect because (1) it is really only usable as a trait, because it interacts with other Area objects; (2) unlike whitespace handling, all fo:blocks have this value, even if 0 it must at least be queried by layout; and (3) fo:blocks can resolve into multiple Area.Blocks (because they could go past one page), only the first of which needs to worry about space-before. Furthermore, this division of fo:blocks into possibly multiple Area.blocks is decided by Layout. So handling space-before is not really fo:block specific, it is actually Area.block-specific.
Note that whitespace handling includes removing spaces around line breaks which are introduced during the layout process.
IIRC flow.Block is parsed into multiple FOText items, each of which get fed into the TextLayoutManager. I'm not certain that "line breaks" are actually being created during layout; rather, during parsing, I suspect the BPD is just incremented and the next line is rendered.