It’s also not absolutely impossible that it’s a legitimate hardware problem — I had two of those Intel desktop processors that destroyed themselves, which often manifested itself early-on as Firefox freezing; Firefox just happened to be really good at tripping problems resulting from that. I also once had a video card that would overheat — part of a line where the manufacturer hadn’t put enough thermal paste or something on the GPU, and if you ran it for a while, it would overheat. But most heat-intensive hardware, CPUs and GPUs, will throttle themselves to avoid overheating; in practice, most overheating problems today tend to result in just worse performance, not instability. I think that heat tends to be blamed more often than it’s an actual cause of instability.

I think that it can be disabled, though I can’t recall the mechanism at the moment (I always want it enabled, and have it enabled on my computer), but normally Control-Alt-F1, Control-Alt-F2, etc will switch you out of Xorg/Wayland to a Linux console. Once out of Wayland and on a Linux console, Alt-Right-Arrow and Alt-Left-Arrow will cycle among the virtual consoles, and Alt-F1, Alt-F2, etc directly switch to one. On my Debian system, the first seven run a text terminal, and the eighth runs Wayland. Especially on modern systems that use KMS (kernel-mode setting) rather than Xorg to manage the video card, that should likely get a system that has something else wrong to a usable, text-based console, as long as the kernel can at least talk to the video card. Probably a good idea to confirm that one can do this ahead of a freeze.

If you have Magic Sysrq enabled (I think that modern distros may have it off by default or restrict some Magic Sysrq combinations; I typically want it available, at least when I control physical access to the computer), that’ll often work if nothing else will, as the kernel grabs it at a low level, though the functionality is pretty limited. Might be able to do Magic Sysrq-k — dunno what happens under Wayland for sure, but that might have the kernel kill off Wayland if it can — and that might get you to a text console or restart Wayland. On my system, I suspect that it’d kill Wayland and my compositor and bring me back to an emptty login prompt, but most people don’t run emptty, so might effectively log them out and bring them back to a graphical login prompt. Can hit Magic Sysrq-t (this will hang things up for a while, then log a backtrace of the running tasks, which can sometimes be helpful to give an indication of what code in the kernel — drivers and such — are running, maybe deadlocked). If you’re on a text console, that output will probably be directly visible. If the kernel is still in a state where it can write to the disk and you’ve got some daemon (journald, under systemd, or older log daemons on non-systemd systems) still functional, that’ll not just display the log to the console, but also log it to the disk. Can persistently enable all the Magic Sysrq key combinations with kernel.sysrq=1 in /etc/sysctl.conf. That’s a bit more specialized — like, if the reason that your screen isn’t showing anything is because the kernel’s just unable to talk to the video hardware to update things, that may not provide useful clues. But if it’s a bug where drivers are actually deadlocked or something, threads are in kernel code and not exiting, that can let you know what code is running (like, “oh, there’s a thread wedged in my Bluetooth driver”). More helpful for tracking down a cause than just saying "well, my system just stopped running and nothing is updating on the screen, even if you’re not a kernel developer.