But, there's sort of a larger problem at stake here with operating systems, and that is the "archaeological WHY".
You see, the way Operating Systems classes are typically taught at university is that you are given an already working, already functional Operating System, which might be as "simple" (a term I use loosely, because it's relative) as Minix. (Minix is not simple compared to DOS, DOS is not simple compared to CP/M, etc.)
But the thing is, while you learn about the different parts of an already functional (multi-functional, because it has many functions) Operating System, you never really learn about the WHY, the reason why, the problem why all of that functionality, all of those systems and subsystems, were established in the first place.
In other words, let's say I have a computer with no OS. Bare metal. And I want the simplest piece of functionality to make my life a little bit easier, like let's say, a simple file system, the ability to run a C compiler, and the ability to use simple commands like "ls", "dir", etc.
Now, that ignores all sorts of other functionality, such as threads, multitasking, locks, IPC, sockets, memory management, GUI, etc., etc.
But, it would allow a greater understanding of the "archaeological WHY".
Once that understanding is firmly solidified, we could explore the next problem on our road to creating a modern, more complex OS. The WHY of that next problem, and the solution to it (increasing in complexity, but building commensurate understanding!) at every step.
OK, I'm rambling!
But I like your idea and greatly endorse it!
This isn't just in Operating System, or Programming but Computer Technology in general. Unlike other Engineering courses from AeroSpace to Mechanical Engineering, which explains everything from basic theory to practice and how we evolve to current design and current ( likely slightly outdated ) industry practice.
...which seems to imply that you're going to need a more efficient language than "traditional" C/C++ if you want to fit more functionality on a single floppy, although given that early UNIX was written in C/Asm, I wonder how much of it is due to bloat/unnecessary/extra abstraction than the choice of language itself.
Granted, I think it's probably easier to limit size (and more importantly, complexity) by using assembly language, it's by no means necessary. Lately I've been exploring minimizing complexity by using less-capable text editors like ed and notepad.
More information, docs, etc: https://pdos.csail.mit.edu/6.828/2014/xv6.html
A few years back I did a quick port of it to x86-64 as a project to learn more about 64bit intel (having been in the ARM world for some time) which was fun: https://github.com/swetland/xv6
I did laugh at this.
The other day I was looking at RetroBSD for example.
but Retro is the more active project https://github.com/RetroBSD/retrobsd
I recommend reviewing this thread.
One interesting thing was that he wants it to be modern but fit on a floppy disk. Modern computers support USB storage which of course is orders of magnitude faster and larger than floppy disks.
Alas, it was not to be.
I wrote some simple silly applications for KolibriOS a while back and it's relatively pleasant (I think a basic GUI window is less code than a Win32 application in C…)
 A MenuetOS fork (which has diverged a fair bit by now): https://kolibrios.org/en/
"UPDATE: Thanks to the Lobsters commmunity, commenting on my Lobsters post, I have come to the conclusion Nanix is unfeasable. That's too bad! "
You'll compile a lot out, sure, but I don't understand from the discussion why it can't be done. I understand why it's hard, why certain people have no interest in it, and why using a 64-bit address space is important for security defense. But nome of that seems to make it fundamentally impossible.
If you think “somewhat useful for hobbyist desktop users” means booting from UEFI, supporting USB-3 including hot-plugging, and doing power management well on generic hardware, I don’t think there’s any chance to stuff everything on a floppy disk.
If you’re willing to remove device enumeration, effectively building a different kernel for each choice of to be supported hardware, work with just a tty over a serial port, and be forgiving a lot on the “Unix-like”, it’s quite doable (example: http://lng.sourceforge.net/, a ‘Unix-like’ OS for the Commodore 64). The “somewhat useful” would suffer, though, and one could argue that isn’t “Unix-like”.
There may be something in-between that adds enough usefulness to make it “somewhat useful”.
If it were me, I'd write an open source RTOS (yet another one) and cast around for clever notions to stick in the thing, for the mental exercise if nothing else. Perhaps carve out a niche in quality/safety and not so much in performance.
I grew with floppy disk (5.25 inches) and, yeah, it's perfectly normal (and fortunate) and the people have forgotten them.
AFAIAC, I have fond memories of them : the sound of the drives (anybody remembers Locksmith, CopyII+,... ?), the hope that the copy you made would work (those floppies were not that reliable), my first experience in cracking, etc.