We discussed this at the Berlin i18n sprint that textgroups have various issues for i18n. They are controlled by a single permission, they don't have rich input widgets, they have inconsistent validation. i18n needs to work around filter formats so that it will not make dangerous things translatable accidentally. Then there is the problem that the user contributed things are not always in the site default language, but we still assume that. Finally if people change the site default langugae, all hell breaks loose because there is no practical way to switch around the data, and we don't do anything about it.
We discussed implementing a simple storage mechanism which would be keyed off of the current context value (and/or pieces thereof). i18n already augments the locale tables with a table on its own for this data, so relying on that would not be a groundbreaking change. However, relating data to those would allow us to move the "default language" to the same levels like the others, so if you change the default language, nothing special would happen, it would just work (wow). Also, we could drop most of the insert-time format handling code since we could just handle it on edit, ensuring that via our own UI. i18n module already mostly generates its own UIs for translation with the new translation tabs, so we'd only need to implement a central translation table to mimic the missing locale functionality.
Finally, really the only negative of this migration will be that gettext .po import/export will be lost. That is in fact not widely used (had/has lots of bugs with Drupal 6 and 7). However, we could augment the new i18n storage with a refactored gettext API that could take data from i18n's data sources or push data there for storage.
Tagging for Drupal 8 Multilingual initiative, since this will be crucial for the D8 migration path, so that when we can safely drop textgroups without loosing data.
Related: core issue to get rid of textgroups in Drupal 8
Related: core issue to refactor gettext API - should be made available as a D7 module too