I've used submodules. In practice they make life harder than monorepos. The code from submodules is checked out as detached HEAD making commits to it behave not as one expects.

I think you have an option to generate all those Builder classes by creating some kind of annotation processor for Java.

You may want to watch TDD proponent help a TDD novice program a Go engine by applying TDD. You may draw some unexpected conclusions from that series, but watching it is tedious.

@naught101: actually, my company has that setting enabled. What happens is that programmer commits his changes locally, then tries push. He gets a response from server that he needs merge before he can push. He gets updates from the server and tries to make a merge commit. At this point I don't know exactly how those persons made a merge commit but on several occasions that merge commit basically erased the changes they got from server.

@romkyns, revised question is much better. I'd still claim that not having to learn basics is the biggest advantage. Developers familiar with XML can focus on learning framework concepts, instead of having to learn syntax at the same time as framework concepts.

I think that the biggest benefit of XAML is not that it can be parsed by XML parsers. It rather is that XAML is similar to XML, and most developers already know how to work with XML, and so learning curve is much less steep.

Actually I would propose this argument as against DCVS. My company recently switched to Mercurial from CVS. People are erasing other peoples changes during merges way more often when on CVS.