Some interesting discussion. Chipping in as the voice of someone a bit at the coalface of real-time (I think), adding an attribute appeals to me, a bit like @convention(c) which I often use in my API. I think I’ll have more to say after I’ve had time to play with adding this pass in my compiler (having trouble building on my Mac M1). It still feels a big ask to add to the main line compiler at this early stage though. It’s ok for custom compiler builds like my forks. I think the need is real but we might find a more complete engineering approach in due course that might make more sense to add to mainline. I want something the wwdc engineers would be comfortable introducing in “what’s new in swift”! 
Another approach might be adding a command line flag to the compiler like —enforce-real-time=true that indicates intent. At first it could add an llvm pass similar to the @realtime above, to make sure only a subset of runtime marked as “real-time safe” (ie predictable, stable and proportionate in execution time... O(1) ish) was allowed and others caused a compiler error. Later that flag could be expanded in use to disable COW somehow, maybe load a slightly different standard library for your target, etc. It would have the advantage of making a catch all and you should know when you’re compiling if a file is intended to produce hard realtime code or not.
For me, I think the fundamental question is “how good is swift at writing bare metal, type, system type code?”.. where you’re comparing to C or Rust. I would love the answer to be “just as good, in realistic use”. So if someone wants to write linux device drivers in swift and they have never touched ios or macs or even UI code themselves, it’s still a natural and painless choice... they gain the defined behaviour and modern syntax of swift and much of the clean architecture of the swift standard library... their code is more accessible to a new generation of coders.
I meant this post to be short... typical me.