For tupleToNameValuePairs, old behavior is not completely irrational but I feel the new semantics make more sense.

SET allow_experimental_nullable_tuple_type = 1;

SELECT flattenTuple(CAST(NULL AS Nullable(Tuple(a UInt32, b Tuple(c String)))));
-- Before: (0,'')
-- After:  \N

SELECT tupleToNameValuePairs(CAST(NULL AS Nullable(Tuple(a UInt32, b UInt32))));
-- Before: [('a',0),('b',0)]
-- After:  [('a',NULL),('b',NULL)]

-- Element cannot be inside Nullable, so emit default.
SELECT tupleToNameValuePairs(CAST(NULL AS Nullable(Tuple(a Array(UInt32), b Array(UInt32)))));
-- Unchanged: [('a',[]),('b',[])]       — return type Array(Tuple(String, Array(UInt32)))

Changelog category (leave one):

• Bug Fix (user-visible misbehavior in an official stable release)

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Fix incorrect handling of NULL rows for Nullable(Tuple(...)) inputs in flattenTuple and tupleToNameValuePairs. flattenTuple now preserves the outer null map so NULL rows stay NULL. tupleToNameValuePairs now changes the result's value type to Nullable(T) when possible when the input is Nullable(Tuple(...)), so NULL rows produce [('a', NULL), ('b', NULL)] instead of [('a', 0), ('b', 0)]. When the element type cannot be wrapped in Nullable (e.g. Array), default values are used instead of NULL. Closes #103312.

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

Version info

• Merged into: 26.5.1.702