Sorry for the harsh message below. Nothing personal, I just don't think that more time should be spent in this direction. But also feel free to ignore me.

So the behavior is
Get the n-th byte, and take the Unicode character corresponding to its value. Don't mind that for most characters this does not work and returns arbitrary gibberish.
The reason that you found use for it in standard library is due to specific optimizations, but replacing the existing explicit actions with this magical method doesn't make things clearer. There is no use for this otherwise, it's clutter at best.

There is no precedent for naming things as chr_at.
There is precedent for char_at which means something completely different.

As for your question: the behavior of String#unsafe_byte_at is undefined for an out-of-bounds index.

In practice, it returns whatever is in the memory after the string (also note that there's one guaranteed 0 byte at the end of the string)

I didn’t find this harsh at all, I fully understand your reasoning!

I cut this PR down to speccing the (defined…) String#unsafe_byte_at behaviour.

Not sure about this, all the other string specs heavily test this internal method so it has coverage already. unsafe_byte_at should probably be protected...

I agree here, I don't think we need to add general unsafe methods, specially when they are not used a lot. At most they should be protected. Same goes with unsafe_byte_at, should be protected or undocumented, can be easily achieved with to_unsafe[I]

Welllll, I tried making String#unsafe_byte_at protected, but it’s also used in IO#gets, HTTP::Params.parse, URI.unescape and URI.unescape_one. 😄 But I do agree with your arguments, closing!

(Let me know if you think adjusting IO#gets, HTTP::Params.parse, URI.unescape and URI.unescape_one to use String#to_unsafe and making String#unsafe_byte_at protected would be welcome, I can happily do that.)

What purpose has unsafe_byte_at as a dedicated method anyway? It's just an alias for to_unsafe[] which is actually shorter...

unsafe_byte_{slice,string} should also be made either :nodoc: or protected. Heavilly prefer the latter.

unsafe_byte_slice_string is already protected and unsafe_byte_slice is only used in file.cr.