I can handle the FPGA side. Start with essentially DOS for RISCV. Use qemu for kernel development, and Verilator as the simulator for RTL. Develop a simple graphics unit that is "pluggable" so you can replace it with a more advanced one later (or if the user requires it). Same for networking.
We'll target one of the ICE40 fpgas with an open toolchain. Not that they're great FPGAs, but the open toolchain is what's important.
I've been batting this idea around for a while.
My side projects generally involve creating my own little Garden of Eden on top of as mainstream a system as the world can muster, which appears at the moment to be Ruby driven by a shell, not sure yet if it's appropriate to try something other than bash. I never even get motivated to drop down to making C extensions, much less reinvent hardware.
If I'm going to reinvent anything at this point it will be the shell, which to me is the most powerful UI abstraction tool available atm. My main gripe at the moment is $PATH. If I want my own tool to be called sort, well the answer is don't do that.
Reinvention is only relevant when you can actually add capabilities that didn't exist before. Then you have to communicate those new capabilities with a killer app. Even my little example, nobody's going to care that I fixed shell tool namespacing if I can't articulate why I needed it with a better system for personal computing.
And if I go and do all that work to make a new shell, it has to solve all the same problems that the status quo evolved to solve. Now that I'm thinking about it, the answer to my dilemma is to invert the shell, make a very basic CLI that delegates to the shell when you really need it, but offers an extensible garden that is free of the shell otherwise. Build on Readline, not bash. I never really needed bash anyway.
I mean, don't get me wrong, I'd be very very happy to implement my side project on the hardware and OS that adheres to your proposed doctrine. Openness is great. But the seething shifting mass of backwards compatibility isn't just going to go away after you reinvent it all. You're just resetting the clock.
My problem with things like Haiku and Reactos is that they're trying to emulate systems that have already existed - Beos and Windows, respectively. All I want is a modern DOS, say with a faster/more capable graphics layer.
The closest I've found is Wirth's Project Oberon, but the choice of language meant that there's very little that can be pulled from existing repositories and used directly - not too many people are programming in Oberon. C is a requirement, but you get that with the RISCV tooling.
Agree on all those goals. Over the years, I've seen some essays and comments scattered all over the web containing those ideas; it would be great to collate all of those thoughts somewhere.