DDSXTY12 — Definition of "strongly assignable" seems to be used inconsitently

if strongly assignable according to section 7.2.4 means that both types should be mutable, then why is the union in Table 15 (section 7.2.4.5, fifth bullet in 2nd column) talking about strong assignability for a T1 that is final or extensible?

• Probably the definition for strongly typed is flawed, and should be about NON-mutable types.

Generally speaking, the overall wording of the subject regarding strong assignability could is causing more confusion than it is clearing things up, and could use some big improvement.

Lots of usecases regarding this subject are underspecified, for example:

• If a type T1 is assignable from a type T2, and T1 has a non-optional member that is not represented in T2, it takes the default (non-configurable) default.
  How can I see the difference between a T1 with a member, that happens to be the default, and a T1 without that member?
  Since 0 is a very common value, it does not seems like a good candidate for default in this case.

Clarified definition of strongly assignable

Updated section 7.2.4 with clearer definition of strongly assignable. Also updated union_type in Table 15 section 7.2.4.5 Aggregation Types.