IS JSON WITH UNIQUE KEYS accepts duplicate member names written with equivalent Unicode escapes

Problem

IS JSON WITH UNIQUE KEYS rejects a JSON object when a member name is repeated literally, but accepts the same duplicate when the second member name is written with an equivalent JSON Unicode escape.

After JSON decoding, the member names are identical. This makes duplicate-key validation depend on the original spelling of the JSON text.

Reproduction

SET SESSION sql_mode = 'STRICT_ALL_TABLES,NO_BACKSLASH_ESCAPES';

SET NAMES utf8mb4 COLLATE utf8mb4_bin;

SELECT

  _utf8mb4'{"a":1,"a":2}' IS JSON AS valid_direct,

  _utf8mb4'{"a":1,"a":2}' IS JSON WITH UNIQUE KEYS AS unique_direct;

SELECT

  _utf8mb4'{"a":1,"\u0061":2}' IS JSON AS valid_escaped,

  _utf8mb4'{"a":1,"\u0061":2}' IS JSON WITH UNIQUE KEYS AS unique_escaped;

SELECT

  _utf8mb4'{"a\\b":1,"a\\b":2}' IS JSON WITH UNIQUE KEYS AS literal_duplicate,

  _utf8mb4'{"a\\b":1,"a\u005Cb":2}' IS JSON WITH UNIQUE KEYS AS escaped_duplicate;

Actual result

On MariaDB 12.3.2:

valid_direct       = 1

unique_direct      = 0

valid_escaped      = 1

unique_escaped     = 1

literal_duplicate  = 0

escaped_duplicate  = 1

The directly repeated key is rejected, but the semantically equivalent escaped key is accepted.

Expected result

All four documents are valid JSON, so IS JSON should return 1.

For IS JSON WITH UNIQUE KEYS, both forms of each duplicate should return 0 because the decoded member names are equal.

Impact

This inconsistency can affect a CHECK constraint based on IS JSON WITH UNIQUE KEYS: a literal duplicate is rejected with warning 4025, while the equivalent Unicode-escaped duplicate is accepted.

No server crash occurred. This is a reproducible wrong-result and data-integrity validation issue.