Re: assuming that only SVG fills open paths: that's true, but it's something of an implementation detail/accident.  Reorganization of other backends might produce the same problem (in particular, postscript has not been ported to the backend tree stuff yet).  And in any case, even so it's not true that we only have to worry about what transparent fill means for backends we don't yet have, since (1) we certainly have to worry about what it means for SVG, and (2) actually we have to worry about it for all backends, since if we are going to be adding transparent fill attributes in `diagrams-lib` then all backends are going to see and process them.

"I think the extra SVG nodes could be removed in an optimization pass on the RTree" -- but that would again require moving the compilation/optimization stuff into `diagrams-lib`.

Re: adding `RTree` passes for reasons other than optimization, I don't feel the same as you.  The point of the `DTree` and `RTree` stuff is not just to optimize, but more generally to do whatever centralized hard work we can in order to make life easier for backends.  We take diagrams and produce simpler `RTrees` with some invariant guarantees that backends can take advantage of in order to make their job easier.  One such guarantee could be, for example, that fill color attributes have no lines in the subtree underneath them.