To me, the advantage of making the SIMD types typed are:

   1. the language does typechecking, for example, trying to add a vector of 4
   floats to 16 bytes would be (and should be) an error.

The language WILL do that checking as soon as we create the strongly typed
libraries. And people will use those libraries, they'll never touch the
primitive type.

I'm not so sure this will work out satisfactorily.

   2. Some of the SIMD operations do map nicely onto the operators, so one

   could write:

      a = b + c + -d;

This is not even true, as you said yourself in a previous post.
SIMD int ops may wrap, or saturate... which is it?

It would only be for those ops that actually do map onto the D operators. (This is already done by the library implementation of the array arithmetic operations.) The saturated int ops would not be usable this way.

Don't try and express this at the language level. Let the libraries do it, and
if they fail, or are revealed to be poorly defined, they can be updated/changed.

Doing it as a library type pretty much prevents certain optimizations, for example, the fused operations, from being expressed using infix operators.

   And, of course, casting would be allowed and would be zero cost.

Zero cost? You're suggesting all casts would be reinterprets? Surely: float4
fVec = (float4)intVec; should perform a type conversion?
Again, this is detail that can/should be discussed when implementing the
standard library, leave this sort of problem out of the language.

Painting a new type (i.e. reinterpret casts) do have zero runtime cost to them. I don't think it's a real problem - we do it all the time when, for example, we want to retype an int as a uint:

  int i;
  uint u = cast(uint)i;