I think UTF-8 is correct here. The ABNF describes octet sequences in a JSON or YAML text.

And https://www.rfc-editor.org/rfc/rfc6570#section-2.1 also mentions UTF-8:

sequence of pct-encoded triplets corresponding to that character's encoding in UTF-8

The ABNF describes octet sequences in a JSON or YAML text.

No, it doesn't. Are we looking at the same section? In https://handrews.github.io/renderings/oas/deploy-preview/oas.html#path-templating and https://handrews.github.io/renderings/oas/deploy-preview/oas.html#server-variable-object, the ABNF shows sequences from %x00 to %x10FFFF. That's not UTF-8 octets -- that's Unicode character sequences. These are decoded characters, not a series of UTF-8 encoded octets.

Further, RFC6570 is clear in several sections that all expansion is done in terms of Unicode codepoints (https://www.rfc-editor.org/rfc/rfc6570#section-1.6, https://www.rfc-editor.org/rfc/rfc6570#section-2, https://www.rfc-editor.org/rfc/rfc6570#section-3.2.1 etc).

The pct-encoded ABNF is UTF-8- and percent-encoded sequences, but the rest of the ABNF is not. But my edit is not in the pct-encoded section -- it is in the section where Unicode codepoints are described.

A final thought: the ABNF in RFC6570 (and also section 1.5) is definitely confusing, and some of it came as a surprise to me -- it's saying that if there is some percent encoding in there, it could be a mix of UTF-8 encoded octets and some Unicode codepoints -- and the way for a reader to tell the difference is to count the number of hexadecimal characters after the percent sign! This is really bizarre and I can't imagine why someone would want to mix encoded and unencoded characters together. Hopefully in the wild we'd only see one or the other, but to handle both in the same string and have to decipher which is which is just gross. It's certainly not something I'm doing right now in my implementation, so I'm going to have to take a look at see if my web framework's URI class handles all this natively or not (I treat the server url prefix as an URL, and un-encode the { and } characters after it has mistakenly translated them to %7B and %7D characters, so as to use it as a uri base for the path template string).

(thank you for coming to my TED Talk)

edit: and I'm a bit wrong here. Where the ABNF is saying %xA0-D7FF etc, it is not saying that this is a percent-encoded unicode character - it's just the literal unicode character itself (I was confused by the ABNF using percent encoding itself to represent a literal -- but this was added in this amendment to the ABNF format here: https://www.rfc-editor.org/rfc/rfc5234#section-3.4). And when we see percent encoding, it's UTF-8-encoded first, so we have a sequence of hex tuplets. But they're still mixing unicode chars with percent-encoded UTF-8 encoded bytes, which is still gross (but is the thing to do to encode non-ascii characters in the path part of URIs).

..and I see https://www.rfc-editor.org/errata/eid6937, well done @baywet :)