

The package archnews2 also provides an arch news reader. This issue was also announced in Arch forums before it was rolled out - I saw it in Lemmy.
But, yeah, you really do have to read archnews release notes. Frankly, it annoys me a bit - pacman should have the concept of breaking changes and show related news before upgrades. I think one of the news packages (maybe archnews2?) has a config setting that always displays news before upgrades, but it’s only annoying because it is ignorant of whether the news item affects any given system, so it’s often just noise; I think I turned it off because it kept showing me the same news every time.
It’s the worst part of Arch, and it’s poorly handled. I don’t know of a rolling release that handles informing the user of, breaking changes better, though.
I think the laptop really does matter, and it’s because chipsets are not all equal in how well their sleep modes are supported in the OS.
I’ve been buying XPS13s for over a decade; I’ve had four (three personal, and one requisitioned for me by my job), and sleep and suspend have worked almost flawlessly on them under Linux. In the office, most everyone else would move between meetings or to their desks with the lids almost closed, to prevent sleep and the problems it caused, but I’d just fearlessly close my lid; it was ironic to me that running Linux on the XPS I had more reliable sleep behavior than the Windows people on their laptops.
For OP: low power, initialization, and restoring state has to be implemented by each chip, and there are a lot of shitty, poorly implemented chips. Then the OS also has to store and restore state for each chipset, and even if the chip implements it well, the OS has to do a good job restoring power in the correct order and restoring the state for each chip. If anything goes wrong in either the chip or driver implementation, you get a broken state.
This is aggravated by the fact that Linux is a monolithic kernel, and if any device drivers get borked it usually borks the whole kernel. This wouldn’t be as bad a problem if Linux were a microkernel architecture and drivers could just be killed and restarted.