You say that the vast majority of apps will ignore $GP sentences. Perhaps that's right in this narrow sector of the market but it is not the case broadly speaking. In fact, most apps in my experience do exactly the opposite - they ignore the 'talker' completely and process every accuracy, position and in-view message on merit; much as you said, the software will ask 'does this make sense? does it meet my accuracy specs?' and if so, will include it. It generally does not care if it's from a GPS ($GP), GLONASS ($GL), blended ($GN) or even LORAN ($LC) source. Unless the end-user specifically opts not to include a source. So it'll ignore the $xx talker and process each GSA, GGA, GSV, RMC, GLL etc message according to the NMEA standard prescribing them.

(For example, in Saudi Arabia GPS is regularly jammed by the military in the vicinity of military installations. For that reason, we filtered out GPS and used only GLONASS data to achieve high-quality results when on survey. Previously the degraded GPS signal was ruining our PDOP. Ok, SkyDemon is not marketed at that part of the world or that particular application, but the MoD here in the UK do conduct GPS jamming trials in some parts of Wales and northern England from time to time.)

So when you say any increased accuracy should be incorporated into the standard $GP messages, I could not disagree more. Receivers should not be offering 'blended' positional information as 'spoofed' $GP messages - they should quite correctly use the $GN prefix for those, and the $GL prefix for GLONASS-only messages. To do any differently would actually contravene the NMEA standard and thus be very bad practice.