Problem: Adding a 2nd (or later) type parameter to a class breaks clients

and incrementally migrating is not easy; it must be done atomically with the type-parameter-increasing change.

This is not a problem when adding the _first_ type paramter:

```dart
class C {}

// This is a non-breaking change:
class C {}

// This is also non-breaking:
class C {}
```

However, when adding any type parameters beyond the first, the change is breaking for any clients which specify any type arguments:

```dart
class C {}

// This is a breaking change:
class C {}

// For code such as the following:
new C();
C c;
class D extends C {}
```

Introducing a second class while renaming the original class is one way to "deprecate" the previous number of type parameters, and expose the "new" number of type parameters:

```dart
class C {
T f1;
dynamic f2;
}

// Non-breaking change:
class C_2 {
T f1;
U f2;
}

@Deprecated("Now with more type parameters! Use C_2!")
class C extends C_2 {}
```

You can ship this non-breaking change, announcing the deprecation, allowing clients to migrate, and later ship a breaking change where you remove `C`.

The big problem with this is that no one wants to rename classes. If you look at functions, it is a breaking change to introduce or remove required parameters (or remove or rename named parameters), but this is mitigated by making optional parameters available. Or perhaps the purpose of a function has changed enough with the changed parameters that you can offer it as a new function with a new name, and keep the old function around, marking it `@Deprecated()`.

Renaming a class seems like a much bigger and unfortunate change. Classes often do not involve more than two words; typically a few nouns, rather than an English predicate expression. "ContainerViewModel" means the Model of a View of a Container, which should not be changed based on the number of type parameters.

Start with the class C, C, and C examples in the issue, then review the surrounding language-change discussions and compatibility constraints. Done would require an accepted design for evolving class type-parameter counts without forcing class renames, along with a documented migration path.

Written by the indexing model from the issue text.