Describe how non-ASCII variable names behave instead of asserting they are unsupported

[Otzie2023]

The current note says PHP "doesn't support Unicode variable names" and then
explains that they work anyway. That leaves a reader with $größe in their
codebase unable to tell what the language actually guarantees.

This replaces the assertion with a description of the observable behaviour:
names are compared as bytes, the encoding is neither interpreted nor
validated, and two names that render identically can be distinct. All three
statements are checkable against the engine today.

It deliberately makes no claim about whether non-ASCII names are a supported
feature. That question is currently open on internals and the manual should
not pre-empt it in either direction:
https://news-web.php.net/php.internals/132344

The look-alike hazard is not hypothetical. In a survey of the 5,000
most-downloaded Packagist packages (520,802 files), 68 identifiers contain an
invisible character. One live example is the Alipay OpenAPI SDK, which assigns
to $chrtext with a trailing U+00A0 and then passes that variable by
reference, so anyone typing the name without the no-break space gets a
silently different variable. Data and tooling: https://github.com/Otzie2023/PHP

[Otzie2023]

You're right, and thank you for catching it -- "other encodings" was too
broad on my part. I reproduced your example:

Shift-JIS 表 = 95 5C   parse error (0x5C is the backslash)
UTF-8     表 = E8 A1 A8   parses
Latin-1   ä  = E4         parses
EUC-JP    表 = C9 BD      parses
UTF-16 (embedded NUL)     parse error

So it holds for Latin-1 and EUC-JP, whose non-ASCII bytes are all >= 0x80,
and fails exactly where you said. Your wording is more accurate than mine
and I have applied it.

[jordikroon]

LGTM. Thank you!