That was a good comment, thanks.

I'll try to clarify a little bit more about what I was talking about and reply to some stuff.

• Window Manager: This is Niri, but of course everyone will have their own preferences for their window manager. For foot pedals you can just search "USB foot pedal" and get lots of results for ordering that sort of thing online. You might also be interested in macro pads, which are basically just little keyboards with extra keys you can use to supplement your primary keyboard. Of course you still have to set that up in software, but it seems like this program can do that for you (I haven't done this myself, so no guarantees lol).
• Better Markup, Responsive Terminal UI, Unified UI: When I mention these things I'm mostly thinking of The Mother of All Demos. You can watch recordings of it on youtube, and its quite remarkable, Douglas Engelbart demonstrates things like rich text (nested lists, collapsible sections), hyperlinks, word processing, the computer mouse, and a slew of other things, all back in 1968 when most people were barely even using an interactive shell (as batch processing was the norm). But the really interesting thing about that demo, in my opinion, is how unified the UI was. It was built for handling a data structure that was basically a linked list of text strings: showing you different views of that data structure and editing it in different ways (opening and collapsing subsections, displaying only a single subsection, 'following' a link like clicking on a hypertext link, its hard to explain succinctly, the best way is just to watch the demo). Which of course works for things like lists of groceries or whatever, but works just as well for files in a file tree, items in a configuration file, the syntax tree of a piece of computer code, or a version control tree. On NLS (the system shown off in the demo), you could use the same interface, the shortcut keys, for interacting with all of these. I don't necessarily think that we should copy NLS in every detail, but you can see what I mean when I say that I think the terminal, file explorer, and document editor could have the same UI. IMO these are all 'text dominated' tasks that could probably be manipulated in the same way.
• Auto Complete: In the first part I'm talking about being able to type something like example.mp4 ffmpeg, instead of ffmpeg example.mp4. In the second case you need to know that ffmpeg exists to begin trying to manipulate the video file, in the first case you could hypothetically type example.mp4 [tab] then get a list of programs that are registered as being able to handle mp4 files, allowing you to discover ffmpeg's existence. This discoverability is one of the big reasons that graphical interfaces are perceived as more user friendly than a terminal. That's what I mean when I say using a noun verb syntax would be more similar to right click (specifically right click --> open with). Of course you'd still want the ability to force a specific program to try to ingest a type of file its not associated with, but you can do that with [right click] --> [open with] too.
• Config Links to Manual: I have heard of that but I haven't used it much (I probably should though). If it works for shell commands I don't see why the same technique couldn't work for config files. The real problem is that so many programs use very different formatting for their configs, and they'd all have to publish detailed descriptions of their syntax in a metasyntax language, along with detailed English documentation of their behavior. So it would be a lot of work to implement. I don't think this is impossible, but I don't think its likely to happen any time soon.
• Indexed Full Text Search: Grep is fine for what it is, but its not indexed search. Search indexing is what allows sites like Google and Wikipedia to search billions of documents, very fast, and with very little CPU and disk usage. Recoll is a program that can do this (and it works on pdfs and epubs too), after you select what directories you want to use it on and build the index, but in my opinion this should be a standard part of the OS's functionality.
• Tags: BeOS (made a typo earlier with the capitalization) was an OS that was around during the 90s. Among a few other neat features it had a file system that let you add arbitrary metadata attributes to files, and optionally index them (a little bit like having Hydrus built into the file system and file explorer). In such a system an email program could be implemented just by adding extra attributes to a bunch of text files in a folder. That makes the email program easier to implement, since it can piggyback off of OS functionality instead of having to come up with something itself, but the real power of that kind of setup is that other programs, like command line utilities, could inspect, search, and modify that metadata in a very easy standardized way.
• File System Snapshot With Version Control: You wouldn't want to make snapshots for every single change, and you probably wouldn't want to keep the full snapshot history for your entire computer (although for some folders you could maybe do either/both of these). Rather you'd mostly take snapshots of your whole disk before big updates or changes, and use them as a restore point (so you typically wouldn't keep ones that are years old). You can do this without file system level snapshots, using programs like Timeshift, but its cheaper from a disk space standpoint to use file system snapshots, and also much faster to create / restore. OpenSuse uses BTRFS to do this, and even lets you boot into old snapshots from the grub menu.
• Plan 9: Plan 9 was built as a successor to Unix, meant to be less crufty and to take the 'everything is a file' philosophy further. For example to take a screenshot in Plan 9 you can execute cat /dev/screen | topng > screenshot.png. Even other devices on the network are represented as (virtual) files in a folder, and everything is accomplished using file operations.
• Namespaces: In general computing a namespace is a mapping from a set of names (or identifiers or whatever) to a set of objects or resources. So, URLs for example, are a namespace that maps a text strings to IP addresses. In Plan 9 a namespace is a mapping between the file system as presented to a specific program, and the actual file system. Processes can modify the namespace of their child processes, allowing them to redirect their inputs and outputs. This lets you do a lot of stuff, for example in plan 9 every program can run without a display server, because every program tries to write directly to the screen 'file'. If you start a program up using a display server and desktop environment its output is redirected to an input on the display server instead. Same goes for audio, and IPC, and so on and so forth, since everything is accomplished using file operations. Using this you can containerize applications, or even run an entire plan 9 userspace nested within the actual userspace. This was invented in the 90s, way before Docker or even the common use of virtual machines. Rather than use a special tool to accomplish something specific, it was accomplished using standard functionality of the OS, that was designed to be applicable to a wide range of situations. This is a common theme in the things I've mentioned.