Thanks for saying this. For me it's unfinished business bordering on an obsession after all this time but I may have reached the point where I can make a Swift Package available that could satisfy the various constituencies. The principle motivation is we need to find an alternative to this sort of abomination:
Using a few well chosen operators this is possible and there is also the novel alternative of a .ascii property on UInt8 suggested by @michelf though that could never trap if you tried to compare a literal that wasn't in the ASCII range. Your point that not trapping may be better is valid but that leaves you in a situation where there is little hope of picking up what is invalid code. It should trap but only for a DEBUG build IMO. You can't do that if the operators where added to the standard library but you can with a package so I think this package may be a better alternative:
The package contains both @michelf 's approach if you import ASCII and the operators approach if you import ImplicitASCII so people get know where the magic is coming from. It took a while experimenting with where to put @inlinable or @_transparent etc. but the final product is performant testing with various branches of swift-syntax (property approach and operators approach). The Implicit approach will give a fatal error on invalid non-ascii cases or comparisons for a DEBUG build and ignores them for a release which seems the best of both worlds. The property approach is marginally faster but the swift-syntax project's tests are not passing which I've not investigated as yet.
It would be better if invalid comparisons would be an error at compile time but that needs support in the compiler and, to avoid breaking existing code pretty soon you need to start looking at pressing single quotes into service with integer conversions to UInt8 
. I looked at that and the changes aren't that onerous but the main obstacle is the current legislative log jam after the last review (which is an interesting read after all this time). There is a a toolchain available if anyone would like to try it out.
Anyway, a bit more data for you. My current position is a Package would be a perfectly fine way to solve this problem since it is possible to get it to be performant which matters for this type of code. Inside the package my preference is for the operators (Ironically I was reviewing the original review and I put them forward in 2019 but nobody picked up on the idea - not even me it would seem). Using a package, people would be able to use either approach or even import a Package for other character encodings.
Edit: In answer to a couple of your questions:
Consider the FixedWidthInteger(unicode:) initialiser "bonus content" I slipped in to provide an alternative to UInt8(ascii:) (which so often has to be subsequently casted) expanded out for unicode values. I've made it a nil-able constructor if the value overflows. I've removed the Array initialiser as it was problematic for embedded systems and people can always write their own.
I didn't consider it to be necessary. Adding still more overloads to comparison operators imposes load on the TypeChecker slowing it down for compiling all code however slightly.