V tomhle případě jde o minimální požadovanou verzi Rustu pro sestavení jádra, která se zvedla. Nejzásadnější důvod bude možnost používání novějších vlastností jazyka a kompilátoru, které verze starší než 1.85.0 nepodporuje.
Jinak přesně stejná verzi Rust kompilátoru bude nejspíš potřeba jen v případě, že byste vyvíjel a sestavoval své nebo nějaké cizí out-of-tree moduly v Rustu a chtěl je zavést do distribučního jádra. Tam, pokud byste používal pro modul jinou verzi toho Rust toolchainu, než byla použitá při sestavování jádra v distribuci, tak byste měl nejspíš problém, protože Rust sám o sobě nedrží kompatibilitu ABI mezi různými verzemi.
Rust leaf moduly (drivery) by měly primárně používat ty nativní Rust abstrakce z crate kernel (bez stabilních pub extern "C" rozhraní).
Jsou tam sice i interní bindingy na céčkové rozhraní konkrétního jádra vytvořené dynamic přes bindgen při sestavování a přístupné pak přes modul ffi, ale ty pokud byly třeba, tak by se měla nejdřív udělat (příp. unsafe) abstrakce/wrapper/helper do crate kernel a pak teprve dál použít v modulu.
Takže bych k tomu přistupoval s omezením na stejnou verzi toolchainu na sestavení podobně jako v případě použití jakékoliv externí crate.
Aspoň takhle to chápu (spíš z hlediska administrátora/správce, než že bych sám psal nějaké moduly).
Také jádro s podporou Rust modulů, když se sestaví, tak má v config jasně čitelné verze Rust kompilátoru a LLVM, co byly použité. Což je, předpokládám, i z tohohle důvodu.
Jinak to byla spíš teoretická úvaha. Tzn. kdy by byla potřeba udržet přesnou verzi Rustu pro dané jádro a ne libovolnou vyšší než minimální. Věřím, že většinově nastává buď situace, kdy někdo sestavuje balíčky s (out-of-tree) moduly, pak není moc důvod nepoužívat stejný toolchain z distribuce jako pro jádro samotné. Nebo má někdo pro vývoj zas rovnou celé své sestavení jádra (i třeba s nějakým dalším debuggováním) a pak používá pořád jeden toolchain.