Really the best strategy would be to take existing Linux desktop staples and send patches that allow them to be reskinned enough to get the consistent L+F they want.
The presumption there is that the UI differences are at the skin level, and not tied to behavior, application architecture, toolkit decisions, etc.
The other approach they could take is the Mono/.net approach, which is to have some core domain logic, and then use that as a back-end for multiple independent UIs. A well-designed back-end allows the UIs to be relatively lightweight and hopefully maintainable.
The trouble is, some of what makes "existing Linux desktop staples" is non-trivial UI work. And sometimes adding a back-end front-end split can add a lot of complexity.
In the end, I think the reason we see such division on the question of custom app VS custom skin VS reusable back-end is that there are serious trade-offs in each direction.
The other approach they could take is the Mono/.net approach, which is to have some core domain logic, and then use that as a back-end for multiple independent UIs. A well-designed back-end allows the UIs to be relatively lightweight and hopefully maintainable.
The trouble is, some of what makes "existing Linux desktop staples" is non-trivial UI work. And sometimes adding a back-end front-end split can add a lot of complexity.
In the end, I think the reason we see such division on the question of custom app VS custom skin VS reusable back-end is that there are serious trade-offs in each direction.