Inconsistent evaluation of ENUM comparison between dynamic CHAR() expression and CTAS materialized column

There is a logic bug / type resolution inconsistency when comparing an ENUM column with a CHAR() function dynamically vs comparing it with a materialized column generated by CREATE TABLE AS SELECT (CTAS).

When inserting '0' into an ENUM('a') column, the value is stored as ENUM index 0 (empty string).
When compared directly against CHAR(0) in a WHERE clause, MySQL coerces the comparison into numeric context (0 <> 0 -> FALSE).
However, when CHAR(0) is materialized into a separate table via CTAS, the field is treated as a string column, causing the comparison to evaluate under string context ("" <> "\0" -> TRUE).

[How to repeat]
– Minimal Reproducible Example (MRE)
DROP DATABASE IF EXISTS test;
CREATE DATABASE test;
USE test;

CREATE TABLE t0 (
e ENUM('a')
);

– Insert '0' which corresponds to ENUM index 0
INSERT INTO t0 VALUES ('0');

– Materialize CHAR(0) into table t1
CREATE TABLE t1 AS SELECT CHAR(0) x, e FROM t0;

– Query 1: Dynamic expression (Numeric coercion) -> Returns 0 rows
SELECT 1 FROM t0 WHERE e <> CHAR(0);

– Query 2: Materialized column (String context) -> Returns 1 row
SELECT 1 FROM t1 WHERE e <> x;

[Suggested fix]
Ensure consistent type coercion rules between dynamic function evaluations and CTAS column type inferencing when comparing against ENUM types.