Edit is now open source

Zellij is a good example of a tui with shortcuts in the UI. Helped me learn them way better than I would have otherwise

No. It was a fundamental conceptual difference in the operating system. After Xenix, Microsoft did not use a terminal paradigm in its operating systems. They all had a "console" paradigm, where instead directly attached VDUs, keyboards, and mice had explicit API support as first-class devices. Because they targetted "personal computers" where one knew from the firmware up that the machine had a VDU, a keyboard, and (possibly) a mouse.

* https://jdebp.uk/FGA/tui-console-and-terminal-paradigms.html

For a long time, so long that I had a widely used 2 decades old Frequently Given Answer about it, Windows NT had no way to capture console I/O, no way of waiting on consoles for buffer changes and to inject back-end input events. No way to do what a SSH server would need to do in order to capture and send/receive that I/O over a network.

Then along came Windows Terminal, and I finally got to change the answer in 2018.

* https://jdebp.uk/FGA/capture-console-win32.html

you gotta make sure that hotkeys get passed in every keyboard configuration. Ctrl, CTRL Shift, Ctrl Caps, Alt, how do tabs work? Etc..

That something looks simple but is actually difficult is an error we all make

It's definitely for that reason. It is amazingly hard to portably do something as trivial in the DOS world as recognize [Shift]+[Ins]. The terminal paradigm is very different to the console paradigm in some areas.

In the days when a Tektronix terminal was a real physical thing that one sat in front of, the TUIs that one used didn't look at all like the ones in the contemporary personal computer world. Ironically, an old Tektronix or DEC VT user transported into the future would be very at ease with what you get in the Linux-based operating system world today.

All that said, the Windows Terminal people have worked pretty hard to get even some of the obscure ECMA-48, ITU T-416, DEC VT, and XTerm stuff into Windows Terminal, so at least TUI applications writers who are prepared to write all of the bizarre hooplah to have things like recognition of [Control]+[Home] and correctly operating reverse video, actually will get them.

The design intent of unsafe Rust is that its usage should be rare and well-encapsulated, but supported in any domain. Alleviating a performance bottleneck is a fine reason to use unsafe, as long as it only appears at the site of the bottleneck and doesn't unnecessarily leak into the rest of the codebase.

The most basic reason why you can't have unrestricted mutable aliasing is because then the following code, which contains a use-after-free bug, would be legal:

    let mut val = Some("Hello".to_owned());
    let outer_mut = &mut val;
    let inner_mut = val.as_mut().unwrap();
    *outer_mut = None;
    println!("{}", inner_mut);

If, as is sometimes the case, you need some kind of mutable aliasing in your program, the intended solution is to use an interior-mutability API (which under the hood causes LLVM's noalias attribute to be omitted). Which one to use depends on the precise details of your use case; some (e.g., RefCell) carry performance costs, while others (e.g., Cell) are zero-cost but work only for certain types or access patterns. Having to figure this out is annoying, but such is the price of memory safety without runtime garbage collection. In the worst-case scenario you can use UnsafeCell, which as the name suggests is unsafe, but works with any type with no performance cost. UnsafeCell is also a little bit heavy on boilerplate/syntactic salt, which people used to C sometimes find annoying; there isn't that much drive to fix this because, as per above, it's supposed to be rarely used.

The "few percent in benchmarks" thing sounds like it's referring to the rule that it's UB to use unsafe code to make aliased &mut references even if you don't actually use those references in a problematic way. Lifting that rule would preclude certain compiler optimizations, and as per above would not fix the real problem; you still couldn't have unrestricted mutable aliasing. It would only alleviate the verbosity cost, and that could be done in a different way without the performance cost (like by adding special concise syntax for UnsafeCell) if it were deemed important enough.

The uninitialized-memory situation is pretty widely agreed to be unsatisfactory. Unfortunately it is hard to fix. Ideally the compiler would do flow-control analysis so that you can read from memory that was uninitialized only if it has definitely been written to since then. Unfortunately this would be a big complicated difficult-to-implement type system feature, and the need to make it unwind-safe (analogous to the concept of exception safety in C++) adds much, much more complication and difficulty on top of that. You could imagine an intermediate solution, wherein reading from uninitialized memory gets you a valid-but-unspecified value of the applicable type instead of UB, but that also has some difficulties, such as unsoundness in conjunction with MADV_FREE; see https://internals.rust-lang.org/t/freeze-maybeuninit-t-maybe... if you're curious for more details.

Again, the point here is not "the current design is optimal", it's "improving on the current design is a difficult engineering problem that no one has solved yet".

I think people who need cursors over linked lists use a third-party library from crates.io for this, but it's quite reasonable to think that the standard library should have this. Most of the time when a smallish feature like that remains unstable it's because nobody has cared enough about it to shepherd it through the stabilization process (perhaps because it's not a hard blocker if you can use the third-party library instead). Possibly that process is too slow and heavyweight, but of course enacting a big process change in a massively multiplayer engineering project that's governed by consensus is an even harder problem.