(Closely related in the original premise, but both the question and its answers go off in a different direction: this meta post.)
Something I've noted in many challenges which are fundamentally about storing a large amount of data in the program (e.g. most kolmogorov-complexity challenges with large output) is that languages which natively use 8-bit (or 16-bit, but that's much rarer) encodings have a large advantage. Unlike most code-golf challenges, where most of the challenge is in writing the code, in this sort of challenge, the program is likely mostly going to be formed by a large string literal (or the language's equivalent), and so the score obtained for a particular algorithm is going to be based primarily (not exclusively, but close to it in most cases) on how efficiently the data can be stored in that literal. If the language uses a 7-bit character set, or a UTF-8-like character set, then many codepoint sequences won't be allowed inside the literal, and thus will run the compression ratio of the program. This seems to unfairly discriminate against languages in much the same way as, say, banning flexible I/O formats does.
It's also a problem because it makes submissions hard to compare in challenges where the algorithm is more interesting than the actual implementation of it (e.g. this answer of mine is much shorter than the next-shortest answer, and most of that comes from algorithmic improvements, but I found it easiest to write it in Jelly and many people are going to end up assuming that the score is based on the language, as they're used to seeing Jelly outgolfing JavaScript and Mathematica by that sort of ratio on challenges which are more about the implementation than the algorithm).
Now, one way to solve this problem would be to ban characters with the high bit set, thus forcing all languages to use a 7-bit character set (this is different from printable-ascii as I don't see a reason to ban nonprintable ASCII here). This would work well for the vast majority of languages (and is something that I've seen suggested at least in the comments of some of these challenges), but rather fails on languages where many builtins contain non-ASCII characters and have no alternative encoding (as it'll make the "code" part of the program much harder to write).
An alternative is to use bonuses/penalties. In particular, I was wondering if it would in general be a good idea to offer a 12.5% bonus if none of the characters in the program have their high bits set. I'm aware of the normal arguments against bonuses/penalties, which make sense for most situations in which they're used, but this is somewhat different, as the decision is likely to be clear-cut, and yet different per language (languages which "natively" use ASCII have no reason not to go for the bonus, languages which use all 256 possible octets typically have no trouble representing them in string literals and thus wouldn't benefit from the bonus at all). The bonus size of 12.5% places the 7-bit and 8-bit (and 16-bit) encodings on an exactly level playing field, and thus will help the focus be on the algorithm, which it really should be in this sort of challenge.
So the question is: is this sort of bonus a good idea? Would it be a good idea even on other types of challenge, or just compression-related ones? Are there other ways we can help avoid unfairly discriminating against languages due to the way in which they store string literals (or the equivalent)?
