Good day,
As of lately I can’t listen to anything while driving, I got plenty of time to think, and mostly is Haiku stuff 
. Regarding the “states”, IMHO I think Haiku needs an improved method to rollback to a “stable” state, and a way to keep certain “states” saved.
Here I was thinking on how to have a tool to do it, though was a wrong approach. Actual Haiku states are text files stored in the /Administrative folder inside /home/config/packages/Administrative IIRC, and they list the installed pieces and their versions. Easy to remove by hand, or with a GUI tool. The replies I got at that post would apply to the GUI, I presume. I didn’t dig any further because lack of knowledge on Haiku 
These days, I was thinking about having the Core OS isolated from the apps, and saving snapshots of “working-stable” Core OS installs. Not sure but I presume this would break the Haikuports stuff, I mean, softwared installed from Haikuports that would depend on certain OS libs. Packaging software with its dependencies could solve this, is this correct?
By isolated I mean that Haiku, the OS could install itself, and update itself independently from apps, and viceversa. As HD’s are becoming bigger (capacity) and cheaper, it could be possible to keep full OS (core) snapshots without taking much space on the disk. Besides, Haiku itself does not take lots of space, as other OSes do. With a GUI tool, user could lock an HREV and keep it on disk to rollback to a fresh state, or whatever.
I’m starting to learn more about the HPKG format, and recently read here in the forum about the disk image stuff. Also, I’m toying around with HPKGs, to see if I can get more familiar with it and get a better undersanding on how it works. I have the feeling that HPKGs are more powerful than expected in many ways.
Some might thing about AppImages, Snaps or Flatpaks for software deployment, and mostly that is the idea. I would need, once Godot is stable on Haiku, to keep several versions of Godot in order to be able to update old Games with the right version of Godot, using the one the game was developed with to reduce developing time and possible flaws. Importing a project from an old version into a new one has been a big mess for me with Unity, and with Godot moving to v.4 it will be even worse I presume, so I rather keep the version of the software the game was developed with. Also applied to Blender, from 2.79 to 2.90, opening files from 2.79 in 2.90 well… Might be my bad though. This could apply to other software too.
All this is wishful thinking at the moment, though I presume it can be doable in the near future in order to get a “safer” more stable OS. Nonetheless, R1 is the short-term goal, and there are plenty of milestones to reach before release, and this is my specific use case.
Regards,
RR