[1] Or at least was, my recollections regarding this are nearly 10-15 years old at this point.
[2] There was one specific person, Daiz from the Underwater/UTW fansub group, that was one of the first people to start encoding his releases in H.264/10bit, and he would get a lot of hate because they tended not to play very well on improper setups, vanilla VLC being among those. "Dammit Daiz", they would say. He eventually bruteforced a tripcode to have H.264 in it just to mess back at them for all the hate. Fun memories.
edit: here we go, a contemporary HN rant from the man himself regarding MPC vs VLC. Looks like summoning Daiz works here too
Last I checked the recommended method to play h.265 files in VLC was to re-encode them.
I also believed this until I got a family support case a couple of weeks ago.
I learned that if the bitrate is too high for the PC to handle vlc badly fails. (This was a fanless Intel PC, so the CPU is very much low end despite not being particularly old.) Of course I would not expect vlc to do any miracles here, but at least I would expect an error message explaining the problem. ffmpeg gives me warnings all the time if buffers are too small etc. In vlc I'd expect it a bit less cryptic...
Ideally it would still play the video with reduced quality. Whether that's at all doable I don't know. Just decoding I-frames would be the most naive approach, but probably also a not lead to very much usable results.
Actually the family member found one solution themselves: Play it at reduced speed. VLC could have figured out that automatically. (And of course give a clear message to the user why it does that.)
It isn't really. It's possible if the video has B-frames but it's hard to predict how much dropping will cause how much recovery, and if you drop almost anything else the possible error is unbounded.