Yes, it does. It always renders internally at 2x which means that's all applications have to support. Then it downsamples the final framebuffer to the resolution of the display.
There is zero point in sampling higher than 48khz. That captures all frequencies up to 20khz or so. 192khz is just a waste of bandwidth for no actual gain.
On the flip side I built a PC back in 2016 (with two SSD's) which went into storage about 6 months later. I just got that PC back this year and it booted up just fine with all the data intact.
Turbo Frames (https://turbo.hotwired.dev/handbook/frames) does this. It does mean pulling in a JavaScript library (and the user having JS enabled) but you don't have to write any.
I'd definitely love to see something like this built into the browser.
At the time Apple Maps came out, Google Maps on iOS was limited to bitmap tiles and had no turn by turn directions, whereas Google Maps on Android had both dynamic vector based maps and turn by turn directions.
Apple Maps forced Google to improve Google Maps on iOS.
Apple Maps data was definitely substandard when it was released, but it has improved considerably since then. I vastly prefer it to Google Maps, especially for turn by turn directions when I'm driving.
If frequencies abover 20Khz are causing audible differences in the audible frequency range then that's considered distortion and there's an issue in your playback chain somewhere.
48Khz can theoretically be better because the anti-aliasing and reconstruction filters can have a gentler slope, but modern oversampling converters make this moot now.
The audio jack on Raspberry Pi's has always been terrible quality anyway. Ok in a pinch but it's not a huge loss. If you want quality analog output from a Pi you need a DAC hat.