Rust has a fundamental assumption of uniform memory (everything addressable is in address space zero), even more so than C, so this will always continue to be more of a problem for Rust on the GPU than just a naming issue. My 2¢ is that, if this really does appear only in rather specific cases, it should be resolved more like VolatilePtr and less like VolatileCell. (&mut VolatileCell<T> can't have the desired semantics.)
Although, hopefully extern type (or even just using ?Sized to prevent mem::swap) could be sufficient for the compiler to be able to soundly treat a type as existing in a separate address space? I haven't really thought about it too too much, despite extern type being a highly desired feature for me.
I am aware that using Rust on the GPU will probably always require some global concessions to safety and guarantees provided by CPU Rust in the name of shader performance, hoping shader validation and GPU architecture will limit the blast radius to only incorrect results in the effected thread cluster.
Picking names familiar to GPU devs is important here. So I think the best option is launch/workgroup/subgroup/thread.
core::arch::wasm is for the wasm target family (both wasm32 and wasm64), so "GPU stuff" could go to core::arch::gpu with cfg(target_family = "gpu").
On the other hand, core::arch items are generally meant to match the vendor intrinsic semantics and naming exactly, with a shared interface outside of arch, so core::gpu makes as much sense as anything else. The alternative would be os::gpu, but with os::ffi moved to top-level, top-level seems fine.
It could be argued that the non vendor intrinsic versions should live in "the GPU version of std," but I really don't know the build system concerns there.
If we look at std::thread for prior art, we would get an API like gpu::available_launch_parallelism() -> NonZero<usize>, gpu::available_workgroup_parallelism_x() -> NonZero<usize> (per-launch), gpu::available_subgroup_parallelism_x() -> NonZero<usize> (per-workgroup), etc.
available_parallelism returns the number per parent because the parent only has that much parallelism available to it, even if an ancestor has access to more parallelism. (Consider a CPU compute cluster with multiple CPUs available as an analogy.)