<<<The biggest problem I've seen in the past was that round trip engineering was non-existent or very weak/unstable. The code that was generated was unreadable.>>>

well this too depends on how you do it.
agreed i thought about it too and if the level of abstraction and the code level are too far from each other, sure, it would be very difficult to match between them in a fast intutitive way. but thats why you have transformations, you transform your own super-hight abstraction level layer into an intermediate (more implementation layer) and than add stuff to that to define more how it works, and then you translate that to UML, which is 1:1 with the code, so its a direct translation.

sure you can go directly from the abstraction to UML, which is fine too, but its more mental work then going at it with inbetween levels where you have time to progressively dig deeper into the implementation, so its easier on the frustration ;). Later to ease maintenance (or reduce complexity) you could merge some of these inbetween metamodels, but then again, this could very easily increase the complexity since now you would have larger metamodels to deal with, hence more complicated transformation programs.

<<<I've seen so many classes that have roseid comments but rose is no longer used. The short of it was that using the tool was more trouble than it was worth.>>>

not so.
yes it takes longer for the learning curve to happen, and to setup tools, write transformation programs, and code generation programs, and to define the metamodels, than to just jump into code and start hacking. But its crystal clear that code writing is by far the smallest part of any but the most basic projects, and instead debugging is the major time -consumer. With code generation refactoring becomes trivial comparing to regular hand coding since you're just tweaking a limited set of code generatiors as oppose to going through the entire code base (even if you're using plugins that help with searching). Also matching requirements and other configuration oriented work becomes transparent, and a much richer set of domain specific tools can be built on top of a well defined model than on top of pure code without a clear source model.

Its a tools problem, not a concept problem. As tools get better the approach will make more sense.
its interesting that the avionics industry is driving a lot of innovation in this area. For example 70% of any military/civil airplane project goes on building/debugging its software, and so modeling is getting bigger and bigger there. dig and you'll see that lockeedMarting is pushing a lot of model oriented resaerch, since it can affect debugging so much.

Its much easier to debug and logically check different models, and progressively decrease the abstraction, through intermediate metamodels. that way when you get to concrete code level the only thing that could go wrong is bugs in the API's, or in the code generators. those are relativelly easy to fix. The main logical and bad-architecture bugs were uncovered in the modeling stage, and thats why the concept is correct