I would not be opposed to a few well vetted operators, but I would push back on the examples you give:
If we have
'1' express a Unicode scalar as @lorentey suggests, many of the examples you give become dramatically simplified. I would be hesitant to further simplify
x == '1'.value to
x == '1', for a similar reason to what we ran into trouble with in terms of adhering to SE-0213: namely, that whether a bare literal with a number expresses that number or its ASCII value is made less clear. In principle, heterogeneous comparison operators that eliminate conversions is fine, but only in the circumstance where there is no possible confusion as to how things are converted, and I do not think we meet that bar here.
'1'...'8', what you are showing here is a good role for regex literals, but this operator is not it. Specifically, an expression like
'A'...'z' would match
'['. This invites user error. A regex literal is sorely needed, but this imitation of it is in my view misguided.
I am not sure why one would need
42 - '0'. I have often needed to offset to or from the ASCII value of '0' or 'a', say, to get the ASCII value of a nearby character, but that is for lack of better facilities that we are attempting to design here, not an end in itself.