Like the move from (I think) 7.12 to 7.13+ where wireless package was dropped on devices not even having wifi ?
I hope not...
It's exactly like that because before 7.13 the functionality (and the menu) of wireless is present on all devices, even those without WiFi. If you don't remember that, read this Wireless Supplicant section on @tangent's page: MikroTik Solutions: Configuration Flotsam.
No need/point to install that switch-marvell package on 7.25 upgrade on devices without that Marvell switch. Upgrade the hap ac2 to 7.25 and enjoy the gained flash space right away.
What you wrote is completely misleading and irrelevant.
The automatic RouterBOOT update has absolutely nothing to do with the RouterOS update.
And besides, RouterOS packages are signed, even if they were downloaded corrupted, they would never have been installed.
If you then made the mistake of not sending the supout files to support, no one will ever know why you were having that problem.
I can only post what happened and how I got around the autosupout issue.
This was the only issue I've had with installing the update by way of the package manager and auto update.
I have the autosupout files!
So say you. How did the manual upgrade work and not the auto update did not work.
Rest-api and hanging sessions are still not resolved, SUP-216995 updated, issue confirmed.
This is just speculation, please send the files to support.
I did. The question is. How soon will I get a answer?
SUP-217400
when will then be now? soon.
Downgraded rb5009upr from 7.24 beta1 to 7.23.1 autosupout file was generated, don't know why, router slow to react in winbox 3, so yes, confirmer this model does difficult.
My point is that someone removing 'excess packages' from a hAP AC2 (wifi-qcom-ac) will not lock themselves out of the device upon a reboot.
The two or three prestera kernel modules included in the arm PKG are the drivers for all of the ports on many arm-based CRS300's. The modules for the 800 series are different; besides, that box has 2 10G ports connected to the Alpine CPU and would function without the prestera module (been there, done that on my CCR2116).
If someone upgrades their switch, sees this new separate marvell/prestera package, and goes "Oh, that's taking up extra space; I don't need that," and deletes it, upon reboot, they lock themselves out of the switch.
I'm not saying it's not a good idea, but the current structure of packages based on CPU (instead of on product) makes moving those kernel modules into their own package a bad idea.
If they moved to a "smarter" packaging system, where the device "knows" what packages it has to have, and marked others as either "optional" or "irrelevant" to the device, that would be super helpful.
I've seen several similar scenarios on my 5009: I update via System Packages, then after the automatic update, the script restarts with "system;info router rebooted by scheduler:AutoUpgradeFirmware." Then, for some reason, upon booting, it says "system;error;critical System rebooted because of ping watchdog timeout" and after about an hour or so, it crashes with a kernel panic. Then, it works fine for weeks.
On my 5009, I configured autosupout .rif files to be sent directly to Mikrotik.
That's a move like:
ROS is not known to protect you from destructive actions.
Is anyone else seeing RouterOS get a DHCP lease from its own DHCP server on 7.22.x?
I've checked for loops and confirmed there aren't any. The behavior started only after upgrading to 7.22.x. Curious whether others have encountered the same issue.
Are you running DHCP Server AND Client on the same interface? 
Yes, I use it to detect rogue DHCP servers on my network. It worked perfectly on RouterOS versions prior to 7.22.
Shouldn't you be using dhcp-snooping for that very same purpose you're trying to achive with running both a client and server on the same interface?
Instead of adding the DHCP client instance, use the DHCP alert feature: DHCP | RouterOS Manual.
That's a nifty feature, good call.
That's the optimal solution, as it not only detects rogue DHCP servers but also prevents them. Unfortunately, it isn't applicable in my network because many sites use unmanaged switches, so DHCP snooping cannot be implemented.