A commit https://github.com/MariaDB/server/commit/a923d6f49c1ad6fd3f4d6ec02e444c26e4d1dfa8 merged in 10.9.2+ disabled numeric setting of character_set_* variables with non-default values. However the corresponding binlog functionality also needs to be fixed.

During binlog generation, server writes charactor_set_client information to binlog based on what character set the client is using, which looks like:

/*!\C utf8mb3 *//*!*/;

SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;

https://github.com/MariaDB/server/blob/ce4a289f1c367987977f1a02bbb8d8b8e8e6bb53/sql/log_event_client.cc#L1973

The problem is that it's totally possible for client to use a non-default value, which is written into binlog as it is:

/*!\C utf8mb4 *//*!*/;

SET @@session.character_set_client=224,@@session.collation_connection=224,@@session.collation_server=33/*!*/;

which is now an invalid statement due to commit https://github.com/MariaDB/server/commit/a923d6f49c1ad6fd3f4d6ec02e444c26e4d1dfa8 and will cause error if this binlog is ever fed back to the server:

ERROR 1115 (42000) at line 38: Unknown character set: '224'

In addition, MariaDB Connector/J has a tendency to use 224 as the default character set, which is non-default, therefore this issue is expected to impact many user who connect to database via Connector/J
https://github.com/mariadb-corporation/mariadb-connector-j/blob/master/src/main/java/org/mariadb/jdbc/client/impl/ConnectionHelper.java#L233

  public static byte decideLanguage(InitialHandshakePacket handshake) {

    short serverLanguage = handshake.getDefaultCollation();

    // return current server utf8mb4 collation

    return (byte)

        ((serverLanguage == 45 // utf8mb4_general_ci

                || serverLanguage == 46 // utf8mb4_bin

                || (serverLanguage >= 224 && serverLanguage <= 247))

            ? serverLanguage

            : 224); // UTF8MB4_UNICODE_CI;

  }