Thanks everyone for your responses! I'm replying here and also adjusting my local copy of the RFC. 
Yes, thanks.
As @Aatch said, not really. The constants have to actually be constants for code-generation: linting isn't enough. For out of bounds accesses, I'm not sure we can tackle every case (and, even if we do have a lint, we have do something for allow/warn, since the code will run at runtime). In particular, my intention is to use something like RFC 1062 to wrap the raw intrinsics, so it's not obvious when an index will be out-of-bounds. (In general it won't be known until code generation time.)
Could you expand? I don't know what linting/checking you're envisioning: it's not possible to check/lint conversions of values that are too large for the target type since the values are only known at runtime in general.
The namespacing is for the compiler to recognise which intrinsic to call, we'd have to have more trickery if we just wanted to use modules (the compiler would have to consider the name of the module when looking at an extern block to work out what it should be doing).
I agree it's an important part of SIMD functionality. However, I'm not sure this RFC is the place to solve it. Certainly the concern essentially only applies to the cfg(target_feature) part of the RFC.
I thought about it before posting this RFC, and I'm not sure how to do it any way other than cfg. I think we may want some way to compile a crate with several different configurations and load them together, similar to the C/C++ method. (I.e. basically C/C++ will compile each file with different configurations.)
I'd be extremely interested in hearing other's thoughts about this.
Good point. I wonder if something like vector.const_div::<10>() works... Or maybe vector / Const::<10> (brainstorming...). Or if we should just eat the performance cliff and allow plain old vector / 10 (or vector1 / vector2) and rely on the optimiser to handle the constant cases.
This sounds like it may something to investigate for libraries to be able to impose type-safety on the raw intrinsics, but the utility of enforcing this on every intrinsic at the compiler level is not totally obvious to me.
It's not obvious to me how much this representation detail matters. 
In any case: we can define [T; n] as another thing that can be repr(simd)'d. If/when we get generic integers that can be used for array lengths, it seems very useful to allow it, but it's not clearly useful right now.
The original intention was to use the attribute as a cue to flatten the representation. Currently we represent Foo in the following with several layers of LLVM structs.
struct Foo(Bar);
struct Bar(Baz);
struct Baz(u8);
However, we need to represent it as a raw u8 (well, i8 in LLVM's parlance). I suppose we could just do this automatically whenever types are used in repr(simd): they're totally flattened. It then becomes the responsibility of the libraries building on this functionality to provide the appropriate bounds to ensure the non-representation properties (i.e. making SIMD-compatibility part of a type's interface).
I'm not sure what you mean. Could you clarify? This RFC isn't proposing how to implement higher-level interfaces but it sounds like this may be what you're talking about?
In any case, debug_assert!s aren't enough to ensure something is a compile-time constant. (Totally minor note: if things are compile time constants there's no reason to use debug_assert over assert: the branches will be statically known.)
Also, shimming with some sort of match to "convert" runtime values into statically known compile-time ones and relying on the optimiser to eliminate the branch for true compile-time ones runs into an exponential explosion: even just shuffling f32x4's requires 84 = 4096 branches, and it grows super-exponentially with the number of elements ((2n)n): certainly totally unreasonable to do u8x16 shuffles in this way.
In any case, I have know idea if this is what you were envisioning. Please correct any of my misunderstandings!