I have not tried your scenario but perhaps a migration would solve it? Like:

http://world.episerver.com/Documentation/Items/Developers-Guide/EPiServer-CMS/75/Content/Refactoring-content-type-classes/

@Johan Book, yes, that's pretty annoying, especially on the production server when you cannot re-create the content types just like that.
Have you tried to change the Name / Description in language files? I haven't tried the migrations either.

Thanks Johan and Dejan. I discovered the "issue" when trying to change name thru lang files. When nothing happened (and I used the new syntax!), I simply tried to rename the type in code. But to my dispair nothing happened then either. Strange thing is that renaming in code works flawlessly for another team member. Same setup, same VM (although db is of course different). So my guess is that there is some kind of state/condition in the database that breaks this behavior. Maybe Episerver wants to have a go at it and see if they can reproduce the error from my data?

I'm not sure the migration approach would be useful in this case as I need to be able to provide localized names, so I really need to get the lang mapping to work... But perhaps migration first and then use lang definitions for the new type name... hmm...

Whoa! Tried to turn off model sync in episerver.config (enableModelSyncCommit="false") and guess what? Both changes made in code AND lang overrides started working. I know they are not persisted to the db this way but are there any issues running like this? And what does this imply? Could be some state in the database which causes the sync logic to abort completely when sync enabled?

Could it be that you for some reason have a higher version in db than in your code (you can see the version of the assembly in db from tblContentType)?

The syncing algorithm works so that if it detects that the db has a higher version (major or minor) than the code then nothing is synched. This is to suppport the case when you have a loadbalanced setup and you upgrade the servers one by one. Then you do not want a "not yet upgraded" site to overwrite what an upgraded synched.

Thanks Johan! That did the trick. We are compiling with a static version number which caused the assembly to have the same number every time. If we increase minor then everything is updated in the Epi DB correctly. Problem is we can't have auto-increment on minor version, so we need to manually change this when we modify anything. But I guess this is something we can live with =)