Have you ever had corrupted data on linux machines? One have the power to repair it, that's great. One can build linux with LFS too, pieces by pieces, that's also nice. But is that modern? They made the same on PDP's too.
You want to change things? Great!
Then go and make an action plan, work out the details, how the whole system needs to work under the hood. Define the basics, how the small pieces will work together.
Because telling: "the day-night cycle must be changed" is easy if one omits all the small but important details, that's why you should create a clearly defined plan, make a proposal and start working on it. Not just talk a about it, but prove your right.
Somebody told here: Haiku went too unixy, you say, Haiku isn't enough unixy.
I say: you guys have opinions.
But formulating your opinions like "this and that must be changed" is disrespectful as it looks like you know everything better. You like to forgot about it, that the PM developers made an action plan, they analized different existing and non-existent solutions, made a proposal, the devs accepted it.
You haven't did that yet, you just told, we loosing cpu power because PM. True.
You told we loosing performance because packaged fs. True.
But does it means: the absolute true and best solution is: revert everything?
In my professional work i met with the same ideas all the time:
We have an simple solution for something. It isn't nice. It isn't good. It doesn't covers all the things. It actually works only in this and that case. It provides bad results in other times.
I went ahead and implemented a completely new solution, massive abstraction in every strategical point to be able to handle the rapid changing under layers.
I worked 2 days long without sleep on this because, you know, deadlines.
It was ready to rock, worked in every case, provided excellent results.
Why do am i telling this?
Because a workmate told: Umm, i don't understand this, so we need to revert back to the earlier state.
I cannot accept reverting, if it means we loose proved technology against a simple, but terrible solution. We can however make it simpler, we don't have to do everything so, as i thought, we arent't chained by deadlines, we can rework it partially to make it easier understandable, we can work on it to provide better performance. We can invent compressed packages what gets repackaged without compression on the end-user site for performance. We can change all the things.
But you meant, we must remove all these things.
So: mate, go and prove! Your turn. Just don't forget to have fun!