With regard to the issues I faced, I think it would be helpful to capture what happened if anyone else faces the very same issues. I did not find anything on the forum regarding a possible recovery procedure so here you go!
After updating to hrev56131 and rebooting, Haiku stopped working due to an issue with the AHCI driver that hrev56134 shortly afterwards solved.
In between, many things happened.
As a temporary countermeasure, I rolled back to the previous working state (hrev56129) and I eventually got my environment back. Apparentely.
The system didn’t completely restore to its former glory as I didn’t manage to run make any longer, for example:
~/Dev/Projects/Weather> make
Error: Failed to find path: No such file or directory
Makefile:140: /etc/makefile-engine: No such file or directory
make: *** No rule to make target '/etc/makefile-engine'. Stop.
This is probably the most apparent symptom of what I believe is a misbehaviour, maybe related to the fact the makefile engine was updated along with other core and non-core packages.
For the records, make stopped working also in other situations after updating Haiku but right before a reboot.
More to that, the rollback is not permanent, after a reboot the current state has always priority. This means that hrev56131 was the default version regardless.
Once hrev56134 was available, I immediately updated while still being on the restored state.
The update did not complete correctly due to a folder not being present in /system/packages/administrative path.
It seems that upgrading from a restored state it’s not well supported.
This turned my Haiku 64-bit partition unbootable as the boot loader was not able to find a consistent set of packages to boot from.
Fortunately, I had a 32-bit installation on another partition still on an old nightly and thus not affected by the AHCI problem.
I was then able to operate on the 64bit affected partition (it seems that my Dell Optiplex 7010 has a bad relationship with USB thumbdrives to boot Haiku from).
It proved that under:
/system/packages/administrative/activated-packages
the list of packages and their respective versions were not correct due to the update process stopped abruptly.
The correct packages corresponding to hrev56134 where not copied into /system/packages/administrative/ but they where under a subfolder called transaction10 (there are other transaction* folders there, I assume they keep a copy of the last update attempt).
I copied the hrev56134 packages to the main /system/packages and fixed the incorrect version number in the activated-packages file.
I also had to delete or move the hrev56131 packages.
Note: I previously tried to use makebootable on the affected partition but I’m not sure if it was a matter of boot record, so I can’t tell if it is a mandatory step to recover the partition.
I rebooted and boom! I had my environment back, fully functional and updated.
I hope you find this useful in case you find yourselves in such a situation.
I also opened ticket #17759