11.2.2 Identity conversions: Floating-point precision orthogonal to type & dynamic <=> object conversions

Currently:

a) Floating-point calculations are allowed to performed in a higher precision than dictated by their "storage" type. (10.2.7)

b) Identity conversions exist so that "T is convertible to T". This allows code like "(int)v" where v is an int, and makes some parts of the formal description easier. (12.2.2)

c) Identity conversion is effectively overloaded to also mean "reduce to storage precision". This means the Standard has to say that an identity conversion _usually_ has no effect at runtime (12.2.2).

The identity conversion does **not** change the type, as the extended precision type is not treated as a first class citizen, rather precision is treated somewhat as orthogonal to the type. It might be worded better in the current Standard, but it works.

Now in the Proposal we introduce dynamic, along with an identity conversion between object and dynamic - so now an identity conversion **can** change the type, we have another effective overload of its meaning...

The way dynamic is introduced means that:

1) quite a few "and dynamic" have been added after "object";

2) in some places identity conversions are introduced where they did not exist before; and

3) we also have "For the purposes of conversion, the types object and dynamic are considered equivalent" (12.2.1) – which might seem to reduce the need for the first two.

Maybe all this could be clearer? Could the statement above from 12.2.1 be given more prominence so as to reduce the need for "and dynamic" changes? Could it be clearer that floating-point precision, not type, is changed or could the higher-precision type become first class (in the Standard)?

So does the proposal introduce dynamic in the best way?

_(Note clause and floating-point also mentioned in Issue ECMA-TC49-TG2/spec#233)_