It's an honor to get a reply from the ELKS inventor! In your own assessment, how much would you say does ELKS have in common with the Linux of back in the day? I've read you say something along the lines of "many of the structures are similar to pre-SMP Linux", but I wonder how much of Linux-of-back-then translated well to x86's segmented memory model without MMU and privilege levels of any kind, and how much of it required significant reimagining. I imagine segmentation instead of paging alone means that the mm layer is probably its entirely own design?

By the way, there used to be some few MMUs for pre-286 x86 CPUs back in the day. It was all extremely custom stuff as far as I can tell. The one I'm mostly familiar with was for 80186, and made entirely out of 74xx style logic chips and a bit of SRAM. It supported page-granular mapping and protection across multiple (hardware-defined) process address spaces + kernel, and even I/O space protection (though original SINIX, the system that used it, did not seem to end up turning on I/O protection for some reason). No on-demand paging though, i.e. page faults had to resolve to killing the process instead of resolving the fault, as the pipelined design of even 8088 CPUs already made restarting instructions entirely unpractical.[1]

It would have been fun to see ELKS support such things, though I don't have the time and energy left to look into that nowadays (especially given that those super-bespoke MMUs were never very common, and are virtually extinct today). I also guess that the more interesting MMUs, i.e. the ones that do have page-granular mapping, also wouldn't fit very well with ELKS in the first place, as it's (presumably) entirely written for segmentation.

[1] There is the famous Silicon Valley lore of a workstation manufacturer running two 68000 CPUs in lock step to work around similar limitations, one CPU running behind the other one so it can be used to "restart" the faulting instruction, but that's a story for another day.