@@ -48,7 +48,7 @@
 - Spark 3.5.8 (audited 2026-05-27): baseline. `MapFromArrays(left, right) extends BinaryExpression with NullIntolerant`; Spark uses `ArrayBasedMapBuilder` to detect duplicate keys (subject to `spark.sql.mapKeyDedupPolicy`) and rejects null keys with `RuntimeException("Cannot use null as map key")`. Comet `CometMapFromArrays` emits nested `CaseWhen(IsNotNull(left), CaseWhen(IsNotNull(right), map(left, right), null), null)` guards so NULL-array inputs return NULL rather than triggering the previously reported native crash ([#3327](https://github.com/apache/datafusion-comet/issues/3327)). The outer key guard preserves Spark's left-before-right evaluation: one `IsNotNull(left) AND IsNotNull(right)` predicate can still evaluate the values child for a NULL-key row in a mixed batch. The native `SparkMapFromArrays` wrapper also validates key/value lengths per non-null row before DataFusion constructs the map, so matching flattened totals cannot pair values across row boundaries.
 - Spark 4.0.1 (audited 2026-05-27): `NullIntolerant` trait replaced by `nullIntolerant: Boolean`. `ArrayBasedMapBuilder` gains the `keyNormalizer` described below.
 - Spark 4.1.1 (audited 2026-05-27): identical to 4.0.1.
-- Floating-point keys (2026-10-14, [#6549](https://github.com/apache/datafusion-comet/issues/6549)): `ArrayBasedMapBuilder` finds a duplicate `FLOAT` or `DOUBLE` key in a `HashMap` of boxed values (`Double.equals`, so NaNs with different bits are one key) and a duplicate struct or array key in a `TreeMap` in the SQL ordering (`-0.0` equals `0.0`). From Spark 4.0 its `keyNormalizer` also normalizes a `FLOAT` or `DOUBLE` key before the lookup, unless `spark.sql.legacy.disableMapKeyNormalization` is set. The native builders compare the keys' bits, so a key type that holds a float at any depth is `Incompatible` on every version (`MapBuilderKeySupport`). `map_from_arrays` falls back to Spark for them. `from` returns its input arrays when no key repeats, so a lone `-0.0` key stays `-0.0` there.
+- Floating-point keys (2026-10-14, [#6549](https://github.com/apache/datafusion-comet/issues/6549)): `ArrayBasedMapBuilder` finds a duplicate `FLOAT` or `DOUBLE` key in a `HashMap` of boxed values (`Double.equals`, so NaNs with different bits are one key) and a duplicate struct or array key in a `TreeMap` in the SQL ordering (`-0.0` equals `0.0`). From Spark 4.0 its `keyNormalizer` also normalizes a `FLOAT` or `DOUBLE` key before the lookup, unless `spark.sql.legacy.disableMapKeyNormalization` is set. The native builders compare the keys' bits, so a key type that holds a float at any depth is `Incompatible` on every version (`MapBuilderKeySupport`). `map_from_arrays` routes them through the codegen dispatcher. `from` returns its input arrays when no key repeats, so a lone `-0.0` key stays `-0.0` there.
 
 ## map_from_entries
 
 
@@ -168,11 +168,7 @@ array whose elements cannot be null in ascending order, Spark's generated code p
 ## Map construction
 
 `map_from_arrays` and `map_from_entries` don't build a map natively when its key type holds a
-`FLOAT` or `DOUBLE` at any depth. Spark finds duplicate keys by value, so NaNs with different bits
-are one key, and inside a struct or array key `-0.0` and `0.0` are one key too. From Spark 4.0,
-unless `spark.sql.legacy.disableMapKeyNormalization` is set, Spark also normalizes a top-level key,
-so `-0.0` and `0.0` are one key and `map_from_entries` stores `0.0`. Comet's native map
-construction compares the keys' bits
-([#6549](https://github.com/apache/datafusion-comet/issues/6549)), so `map_from_entries` runs
-through the codegen dispatcher instead, and `map_from_arrays` falls back to Spark. `FLOAT` and
-`DOUBLE` values don't affect either function.
+`FLOAT` or `DOUBLE` at any depth. They run Spark's code through the codegen dispatcher instead, so
+duplicate keys, including NaNs and zeros of either sign, behave as in Spark. `FLOAT` and `DOUBLE`
+values don't affect either function. The expressions' entries in the
+[expression compatibility guide](expressions/map.md) give the reason.
@@ -408,7 +408,7 @@ to Spark ([#2837](https://github.com/apache/datafusion-comet/issues/2837)). Enab
 | `map_concat` | ✅ | Codegen dispatch |  |
 | `map_contains_key` | ✅ | — |  |
 | `map_entries` | ✅ | Native |  |
-| `map_from_arrays` | ✅ | Native | `FLOAT` or `DOUBLE` keys and `spark.sql.mapKeyDedupPolicy=LAST_WIN` fall back to Spark ([details](compatibility/expressions/map.md)) |
+| `map_from_arrays` | ✅ | Hybrid | `FLOAT` or `DOUBLE` keys and `spark.sql.mapKeyDedupPolicy=LAST_WIN` route through the JVM codegen dispatcher ([details](compatibility/expressions/map.md)) |
 | `map_from_entries` | ✅ | Hybrid | BinaryType keys/values, `FLOAT` or `DOUBLE` keys and `spark.sql.mapKeyDedupPolicy=LAST_WIN` route through the JVM codegen dispatcher ([details](compatibility/expressions/map.md)) |
 | `map_keys` | ✅ | Native |  |
 | `map_values` | ✅ | Native |  |
 
@@ -34,7 +34,7 @@ import org.apache.comet.shims.CometTypeShim
 private[serde] object MapKeySupport {
 
   private val floatingPointReason: String =
-    "Spark normalizes floating-point map keys, so `-0.0` matches a `+0.0` key and all `NaN`s " +
+    "Spark looks a key up in its SQL ordering, so `-0.0` matches a `+0.0` key and all `NaN`s " +
       "match each other; Comet's native map lookup compares the raw Arrow values."
 
   private val collationReason: String =
@@ -51,9 +51,10 @@ private[serde] object MapKeySupport {
    * finds a key with `TypeUtils.getInterpretedOrdering` over the keys `ArrayBasedMapBuilder`
    * stored, having first normalized them, while native `map_extract` compares the Arrow values as
    * they are, so decline the key types where those disagree:
-   *   - `ArrayBasedMapBuilder` rewrites a `-0.0` key to `+0.0` and canonicalises `NaN`, and
-   *     `nanSafeCompareDoubles` treats `-0.0` and `+0.0` as equal, so Spark answers a `-0.0`
-   *     lookup from a `+0.0` key where native finds nothing.
+   *   - `nanSafeCompareDoubles` treats `-0.0` and `+0.0` as equal and all `NaN`s as equal, so
+   *     Spark answers a `-0.0` lookup from a `+0.0` key where native finds nothing, on every
+   *     version. (How `ArrayBasedMapBuilder` treats float keys when it builds a map differs by
+   *     version; see `MapBuilderKeySupport`.)
    *   - a non-default collation compares under rules native applies as `UTF8_BINARY`.
    *   - for a complex key type, `map_extract`'s `coerce_types` returns the map's exact key field
    *     type, so Comet's planner casts the lookup key to it. That cannot reproduce Spark's
@@ -134,13 +135,8 @@ object CometMapExtract extends CometExpressionSerde[GetMapValue] {
 
 /**
  * Shared gate for the native map builders, `map_from_arrays` and `map_from_entries`, which tell
- * keys apart by their bits. Spark's `ArrayBasedMapBuilder` finds a duplicate `FLOAT` or `DOUBLE`
- * key in a `HashMap` of boxed values, where every NaN is one key, and a duplicate struct or array
- * key in a `TreeMap` in Spark's SQL ordering, where `-0.0` equals `0.0` too. From Spark 4.0 it
- * also normalizes a `FLOAT` or `DOUBLE` key before the lookup, unless
- * `spark.sql.legacy.disableMapKeyNormalization` is set, so the two zeros are one key and
- * `map_from_entries` stores `0.0`. A key type that holds a float at any depth is therefore
- * `Incompatible` on every version.
+ * keys apart by their bits. A key type that holds a float at any depth is `Incompatible` on every
+ * Spark version; `floatingPointReason` explains why.
  */
 private object MapBuilderKeySupport {
   val floatingPointReason: String =
@@ -173,7 +169,9 @@ private object MapKeyDedupPolicySupport {
       .equalsIgnoreCase(SQLConf.MapKeyDedupPolicy.LAST_WIN.toString)
 }
 
-object CometMapFromArrays extends CometExpressionSerde[MapFromArrays] {
+object CometMapFromArrays
+    extends CometExpressionSerde[MapFromArrays]
+    with CodegenDispatchFallback {
 
   override def getIncompatibleReasons(): Seq[String] =
     Seq(MapBuilderKeySupport.floatingPointReason, MapKeyDedupPolicySupport.incompatibleReason)
 
@@ -58,15 +58,15 @@ SELECT element_at(map('a', 1, 'b', 2), 'a'), element_at(map('a', 1, 'b', 2), 'mi
 
 -- Spark stores `-0.0` map keys as `+0.0` and compares with `nanSafeCompareDoubles`, so a `-0.0`
 -- lookup finds the `+0.0` key. Native lookup compares the raw Arrow values.
-query expect_fallback(Spark normalizes floating-point map keys)
+query expect_fallback(Spark looks a key up in its SQL ordering)
 SELECT element_at(map(CAST(0 AS DOUBLE), 7), CAST(-0.0 AS DOUBLE))
 
-query expect_fallback(Spark normalizes floating-point map keys)
+query expect_fallback(Spark looks a key up in its SQL ordering)
 SELECT element_at(map(CAST(0 AS FLOAT), 7), CAST(-0.0 AS FLOAT))
 
 -- The floating-point decline walks every nesting level of the key type, so an array-of-double key
 -- falls back for the same reason.
-query expect_fallback(Spark normalizes floating-point map keys)
+query expect_fallback(Spark looks a key up in its SQL ordering)
 SELECT element_at(map(array(CAST(0 AS DOUBLE)), 7), array(CAST(-0.0 AS DOUBLE)))
 
 -- A complex key type: `map_extract` casts the lookup key to the map's exact Arrow key type, so a
 
@@ -44,5 +44,5 @@ CREATE TABLE test_map_double(m map<double, int>) USING parquet
 statement
 INSERT INTO test_map_double VALUES (map(CAST(0 AS DOUBLE), 7)), (map(CAST(1 AS DOUBLE), 8)), (NULL)
 
-query expect_fallback(Spark normalizes floating-point map keys)
+query expect_fallback(Spark looks a key up in its SQL ordering)
 SELECT m[CAST(-0.0 AS DOUBLE)] FROM test_map_double
@@ -15,12 +15,10 @@
 -- specific language governing permissions and limitations
 -- under the License.
 
--- Map keys that hold a FLOAT or DOUBLE (#6549). Spark finds a duplicate top-level key in a HashMap
--- of boxed values, where NaNs with different bits are one key, and a duplicate struct or array key
--- in a TreeMap in its SQL ordering, where -0.0 equals 0.0 too. From Spark 4.0 it also normalizes a
--- top-level key, so map_from_entries stores 0.0 for -0.0. The native builders compare the keys'
--- bits, so map_from_entries runs through the codegen dispatcher and map_from_arrays falls back.
--- Top-level zeros, which only Spark 4.0+ merges, are in map_builders_float_keys_spark_4_0.sql.
+-- Map keys that hold a FLOAT or DOUBLE (#6549) are declined by the native builders. See
+-- `MapBuilderKeySupport.floatingPointReason` for how Spark treats them. map_from_entries runs
+-- through the codegen dispatcher, as does map_from_arrays. Top-level zeros, which only Spark 4.0+
+-- merges, are in map_builders_float_key_gate_spark_4_0.sql.
 
 -- Parquet canonicalizes NaN, so negating a stored NaN gives one with the sign bit set.
 statement
@@ -39,52 +37,59 @@ SELECT id,
   map_keys(map_from_entries(array(named_struct('k', -f, 'v', 1), named_struct('k', 2.5F, 'v', 2))))
 FROM float_map_keys
 
-query expect_fallback(native map construction compares the keys)
+query expect_dispatch(map_from_arrays)
 SELECT id,
   map_keys(map_from_arrays(array(-d, 2.5D), array(1, 2))),
   map_keys(map_from_arrays(array(-f, 2.5F), array(1, 2)))
 FROM float_map_keys
 
 -- NaNs that differ only in the sign bit are one key on every version.
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_entries(array(named_struct('k', d, 'v', 1), named_struct('k', -d, 'v', 2)))
 FROM float_map_keys WHERE id = 2
 
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_entries(array(named_struct('k', f, 'v', 1), named_struct('k', -f, 'v', 2)))
 FROM float_map_keys WHERE id = 2
 
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_arrays(array(d, -d), array(1, 2)) FROM float_map_keys WHERE id = 2
 
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_arrays(array(f, -f), array(1, 2)) FROM float_map_keys WHERE id = 2
 
 -- Struct and array keys compare in Spark's SQL ordering, where -0.0 equals 0.0, on every version.
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_entries(array(
   named_struct('k', named_struct('x', d), 'v', 1),
   named_struct('k', named_struct('x', -d), 'v', 2)))
 FROM float_map_keys WHERE id = 1
 
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_entries(array(
   named_struct('k', array(f), 'v', 1),
   named_struct('k', array(-f), 'v', 2)))
 FROM float_map_keys WHERE id = 1
 
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_arrays(array(named_struct('x', d), named_struct('x', -d)), array(1, 2))
 FROM float_map_keys WHERE id = 1
 
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
+SELECT map_from_arrays(array(array(d), array(-d)), array(1, 2)) FROM float_map_keys WHERE id = 1
+
+-- NaNs that differ only in the sign bit are one key inside an array key too.
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_arrays(array(array(d), array(-d)), array(1, 2)) FROM float_map_keys WHERE id = 2
 
 -- Distinct keys still build a map.
 query expect_dispatch(map_from_entries)
 SELECT id, map_from_entries(array(named_struct('k', d, 'v', 1), named_struct('k', d + 1, 'v', 2)))
 FROM float_map_keys WHERE id IN (1, 3)
 
+query expect_dispatch(map_from_arrays)
+SELECT id, map_from_arrays(array(d, d + 1), array(1, 2)) FROM float_map_keys WHERE id IN (1, 3)
+
 -- Only the key type matters: a FLOAT or DOUBLE value stays native.
 query expect_native(map_from_entries)
 SELECT id, map_from_entries(array(named_struct('k', id, 'v', d), named_struct('k', id + 10, 'v', -d)))
 
@@ -17,8 +17,8 @@
 
 -- With spark.sql.legacy.disableMapKeyNormalization, Spark 4.0+ leaves FLOAT and DOUBLE map keys as
 -- they are, as Spark 3.4 and 3.5 always do (they don't have the flag). So 0.0 and -0.0 are two
--- keys and a -0.0 key stays -0.0. map_from_entries runs Spark's code in the codegen dispatcher,
--- which has to see the session's flag.
+-- keys and a -0.0 key stays -0.0. map_from_entries and map_from_arrays run Spark's code in the
+-- codegen dispatcher, which has to see the session's flag.
 
 -- Config: spark.sql.legacy.disableMapKeyNormalization=true
 
@@ -34,7 +34,7 @@ SELECT
   map_keys(map_from_entries(array(named_struct('k', -f, 'v', 1), named_struct('k', 2.5F, 'v', 2))))
 FROM float_map_keys_legacy
 
-query expect_fallback(native map construction compares the keys)
+query expect_dispatch(map_from_arrays)
 SELECT
   map_keys(map_from_arrays(array(d, -d), array(1, 2))),
   map_keys(map_from_arrays(array(f, -f), array(1, 2)))
 
@@ -17,7 +17,7 @@
 
 -- From Spark 4.0, ArrayBasedMapBuilder normalizes a top-level FLOAT or DOUBLE key before it looks
 -- for a duplicate, so 0.0 and -0.0 are one key (#6549). Earlier releases keep them apart, and so
--- does spark.sql.legacy.disableMapKeyNormalization (map_builders_float_keys_legacy.sql).
+-- does spark.sql.legacy.disableMapKeyNormalization (map_builders_float_key_gate_legacy.sql).
 
 -- MinSparkVersion: 4.0
 
@@ -27,16 +27,16 @@ CREATE TABLE float_map_keys_zeros(d double, f float) USING parquet
 statement
 INSERT INTO float_map_keys_zeros VALUES (0.0, 0.0)
 
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_entries(array(named_struct('k', d, 'v', 1), named_struct('k', -d, 'v', 2)))
 FROM float_map_keys_zeros
 
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_entries(array(named_struct('k', f, 'v', 1), named_struct('k', -f, 'v', 2)))
 FROM float_map_keys_zeros
 
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_arrays(array(d, -d), array(1, 2)) FROM float_map_keys_zeros
 
-query expect_error(DUPLICATED_MAP_KEY)
+query expect_error_class(DUPLICATED_MAP_KEY)
 SELECT map_from_arrays(array(f, -f), array(1, 2)) FROM float_map_keys_zeros
@@ -17,10 +17,14 @@
 
 -- Verifies that `map_from_arrays` falls back to Spark when `spark.sql.mapKeyDedupPolicy` is set
 -- to `LAST_WIN`. Spark's ArrayBasedMapBuilder keeps the last occurrence of each duplicate key;
--- Comet's native `map` scalar has no LAST_WIN path, so it must fall back. The default `EXCEPTION`
--- mode agrees with Comet and is covered by `map_from_arrays.sql`.
+-- Comet's native `map` scalar has no LAST_WIN path. `CometMapFromArrays` mixes in
+-- `CodegenDispatchFallback`, so its native `Incompatible` normally routes through the JVM codegen
+-- dispatcher; we disable the dispatcher here so the incompat branch surfaces as a genuine Spark
+-- fallback rather than in-pipeline codegen. The default `EXCEPTION` mode agrees with Comet and is
+-- covered by `map_from_arrays.sql`.
 
 -- Config: spark.sql.mapKeyDedupPolicy=LAST_WIN
+-- Config: spark.comet.exec.scalaUDF.codegen.enabled=false
 
 statement
 CREATE TABLE test_map_from_arrays_dedup(k array<string>, v array<int>) USING parquet