The new I18N system does not play nice with the JCR extends mechanism because an extended definition has a new name and will therefore generate translation keys with this new name. So if I extend an App - all of the items with keys that depended on that apps name - will now be untranslated.
This is a dealbreaker for Templating because the extends mechanism is so important to effective work. With the new i18n system if I extend a dialog, I would have to copy all of the existing translations for the tabs and fields and change there keys to match the name of the new dialog.
Lets say we have a dialog named basicLink, and we extend it with superLink, which is extended by superDuperLink.
A key might be
joesModule.dialogs.basicLink.tabLink.title.label

There is a POC for dialog key generator in linked PR. We'd need the similar change in most of the generators. It's kind of effort to do this everywhere. The question is if it's worth the effort or we can solve most of the problems by using of less specific keys. (e.g. tabMain.fieldNam,label instead of dialogWhichOtherDialogsExtendsFrom.tabMain.fieldNam.label)