But why

That would depend what "this kind of functionality means". For example Linux really can't abide floating point, so for them it's crucial that you can't by any means end up doing floating point operations in Rust for Linux unless you've spelled out that intent very clearly. Unsurprisingly in most applications it's enough that (as is true in stable Rust) you don't stumble onto floating point operations when you never needed them. For example in Rust, just as in C, 5 / 2 is 2 because it's not performing a floating point divide and then transmuting the type as it would in say, Python.

So to adjust from "Yeah, so don't do that" to "We'll make sure you won't do that" Rust for Linux needed tweaks and the stable Rust does not have those tweaks.

Are you astonished that nobody else had this requirement? Nobody in embedded cares, most of the other operating systems are not in a place where "enforce micro-optimisation of context switch overhead" is a focus. If there are people who care (maybe at Microsoft?), and are using Rust for the OS kernel, they're not advertising this use.

In 2023 you could point at alloc, back then Rust for Linux relied on a fork of alloc because Linus requires that allocations are fallible at the point of use, which means all the Rust APIs which panic on allocation failure must be removed from Rust for Linux. Rust's core does not allocate - it doesn't have an allocator so it can't, and Rust's std layer requires an operating system so it will never be part of Rust for Linux - we're implementing the OS not using it. But alloc was in the middle, and so for a period Rust for Linux forked it. That's done, the stable Rust ships all the explicit allocation failure stuff which Linus insists on.

But actually in alloc we do see things where (I did not check specifics) Rust for Linux might want them but they aren't in stable Rust today. Vec::push_within_capacity for example. In C you'd just use it and YOLO. In Rust that will not work† and you must ask for nightly Rust if you want these features.

† You could use Mara's nighty_crimes! macro or write your own, but that's not a serious suggestion and in practice amounts to the same thing.

I think this whole effort _is_ the process by which the specific changes needed for Rust to support the existing Linux kernel (rather than a custom all-Rust kernel or userspace application) become mature, Rust is clearly capable of it, the clock for stability _starts_ when the implementation of Rust is ready, but it's only marked as "stable" after some time of real-world use. A half-thought-through analogy is that some special vintage wine is the same liquid put in the bottle the day it was made, when it wasn't special, but time and some tiny changes made it special later, a feature might land in nightly but with time and some tiny changes it becomes stable infrastructure, but it was substantially there the day it was made in nightly. Rust for Linux is going to take several more years to all come together and be seen as old-and-stable, but that is the trend.