Looking at the end of your Xorg.0.log, I see it progressively failing to load various video drivers due to permission issues, then exiting with a "no screens found" error:

[   646.568] (EE) open /dev/dri/card0: Permission denied
[   646.568] (WW) Falling back to old probe method for modesetting
[...]
[   646.569] (EE) Unable to find a valid framebuffer device
[   646.569] (WW) Falling back to old probe method for fbdev
[...]
[   646.569] (EE) open /dev/fb0: Permission denied
[   646.569] vesa: Refusing to run, Framebuffer or dri device present
[   646.569] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[   646.569] (EE) Screen 0 deleted because of no matching config section.
[...]
Fatal server error:
[   646.569] (EE) no screens found(EE) 

A similar thing happened to me several days ago after an Excalibur update. The system had an Intel iGPU and had been using the modesetting driver, which stopped working for unknown reasons. I suspect it was related to the usrmerge issues, as it happened at the same time as other confirmed usrmerge issues. I was able to get X running again by forcing it to use the Intel driver. It's possible the modesetting driver would work again now that I've merged /usr, but I haven't had a chance to test it.

The issue JWM-Kit references likely doesn't affect you if you're running Windows 7. As far as I can tell, Windows' "fake shutdown" "fast startup" was implemented starting in Windows 10.

For those unfamiliar with this "feature," here's how it works. When you tell Windows 10+ to "shut down," it just... lies to you. It instead invokes sleep state S4, aka hibernation or suspend to disk. Whether or not you pull the plug at this point has no bearing, as power is not required in S4, because the system state has been saved to non-volatile memory. If you want Windows to actually shut down, you need to hold down Shift when you select the shut down option. Fast startup can also be permanently disabled in Power & sleep settings.

Thanks for the info, everyone. I was dreading having to install PA, but some applications absolutely require it.

Does anyone know if PW supports CLI control in the same way as PA, for example, with pactl & pacmd? I need it for my volume hotkey scripts, among other things. More on PA CLI control here:
https://shallowsky.com/linux/pulseaudio … -line.html

Apparently dpkg started displaying a warning about this issue to users sometime last year, I'm not sure if it still does. Someone filed a bug report about it last year:
https://bugs.debian.org/cgi-bin/bugrepo … 994388#132
More discussion at lwn.net, including a comment from the responsible party, and some critical responses:
https://lwn.net/Articles/889026/
I can't vouch for the accuracy of the comments, but one person in the lwn.net thread posted the following:

I may have encountered this issue today when I upgraded Excalibur on a couple of different laptops. I saw some eudev errors during boot, but I wasn't able to find any related info anywhere in /var/log. Is there somewhere else these errors might have been logged?

Anything that accessed the display backlight had stopped working: console blanking no longer turned off the backlight, and brightnessctl couldn't find the display. Also, I'm not sure if it was related, but X would no longer start with the modesetting driver. Oddly, it still worked with the Intel and nouveau drivers (on different machines.)

I went ahead and installed the usrmerge package. It failed on the first pass, but I got lucky, and only had to delete a few relatively unimportant files to get it to finish. Everything seemed to be working normally again on the next boot, with no errors reported.

Edited to add: I just ran usrmerge on the second laptop with zero errors, which was a pleasant surprise. The backlight is working again on this machine as well; however, a Minecraft server is still failing to start, so it appears I still have other issues. The Minecraft issue was due to a Java update, and unrelated to usrmerge. All is now working on this system as well.