BSODs never offered much useful information.
I started using Windows in the 90s and for years following I would swear I could use infomation from BSODs to fix the issue. In retrospection I say it was no more than a mixture of shotgun debugging, magical thinking, and cherry-picking successes. Most often the information was meaningless for practical purposes. Where it could be useful, the practice of barring access to information by software vendors was rendering it useless. The relatively rare positive outcomes? Correlating the crash with other information, though at the time I’d be convinced it wa due to what I saw in the BSOD. Misinterpreting the information, but by sheer luck it connecting me with the solution. The few instances, where it happened to match an error recently seen by other users.
If you believe BSOD helps you, as I did back then, ask yourself: is it so or are you making the same mistakes I made.
Now I see BSOD as nothing more than a way to tell the user “this is the end.” The design should follow the function. So just make it nice, avoid confusion, reduce pointless frustration. The actual technical details should nowadays go to logs and dumps. There they can be retrieved and give much, much richer information than any BSOD could offer. I suppose we all hate the meaningless “something went wrong” messages, followed with generic and useless hints. But observe this is only, because we miss any alternative way to access the details. Which is not the case, when they’re written into logs.
Putting details in BSOD is also questionable from security standpoint. Anybody seeing the screen can access potentially sensitive information.