If the code is generated from the diagrams, why check the code in at all? Feels akin to checking in the bytecode with your the java that generated it.
The second guess is that humans occasionally rewrite the code for optimization. It might then be easier to source controll the code rather than patches.
Now, I would expect you to have an artifact repository. To that end, you would be able to easily get the generated sources. But, they would decidedly not be in the source repository.
We feel that code generation is something one does explicitly while modelling, not something done every time you build.
Our tool also allows developers to review proposed code changes before choosing to commit them to disk.
Code generation is something you choose to do explicitly as you model.
Optimization can almost make sense, but maintaining a patch process is almost certainly the superior way to go. If only because it supports staying current on the generated code.
This is very useful for cases where you want to model signatures of methods in our tool, but then leave it to the developer to implement the method which performs the business code. If you want to change the signature of the method, for example adding a parameter, then our code generation will add it in without messing up your custom code.
Our own templates generate code which is as beautiful looking and readable as code written by the best developers, and we encourage template writers to do the same. This makes working with the code in your IDE and reading it as much of a pleasure as any other well written code, having it in your SCM also gives you a history of how the code has changed over time.
Finally, use of the tool is optional, if you hand the the repository over to another team, or as a contracter you deliver it to a client, they don't need the tool, and just get code which looks as if it was written by a good developer.
For the other cases you gave, that sounds like what Interfaces were made for. :) Granted, I think we are in a world where tooling not necessarily requiring language constructs is a better place.
Regardless, if you are seeing such success, I would be greatly interested in seeing you open up that tool.
"No lock in" is an important aspect for us. We know of some other big players with "RAD" type tools which "generate" code, but unless one continues using their tool, the code they're left with is effectively unusable. Their business models are also often around runtime licensing.
As devs, building a tool for other devs, we want our tool to continue to be used because people clearly find the value in it, not because they feel locked in.
Anything you do that increases the time between the introduction of the bug and the finding of the bug will make it harder to actually fix it.
This allows developers to feel in control of what's changing in their code base during generation, rather than being worried that some custom code is going to get wiped out by code-gen without them realizing.
In a past project I was on, we had our solution build process run T4 templates to generate code, and it significantly slowed down the build process.
We feel code generation is something you explicitly do when you're "modelling", it's not something that's necessary to create a build nor should it create run-time dependency.
My fear is typically around having "mixed edited" code. That is, code that is edited by hand and generated. I greatly prefer being able to know that the generated stuff is extended by language mechanisms and I will never really have even the ability to edit something that the generator will do. I have seen bugs in generated code, but I have always pushed to fix the generator, not just fixed the generated code. (That make sense?)
And, reiterating because I feel it is important, your position is awesome. Thanks for sharing!