The release has a consensus rule and a stricter policy rule. That difference is why older mining rewards can look locked even when they are still valid to spend in a block.
A newly mined reward normally cannot be spent until it has 100 blocks of confirmation.
On mainnet, the release defines a long-maturity window beginning at block 973440 and ending before block 979920.
Both matter, but they answer different questions.
Consensus decides whether a block is valid. If a transaction breaks consensus, nodes reject the block that contains it.
Policy decides what a node will accept into its mempool, relay to peers, and usually offer to miners.
For block validation, the code checks the height where the coinbase was created.
The mempool path uses a start height of 0. That makes every coinbase look subject to the 6480-block policy rule, even if it was mined long before 973440. In this release, that policy is not limited to the consensus window.
This is the part that sounds contradictory until the two rulebooks are separated.
So an older reward can appear “immature” in the wallet even though consensus would allow it in a block.
Bitcoin Knots 29.4.2 does not retroactively change consensus for coinbases mined before block 973440. Those old rewards still only need the normal 100-block maturity to be valid in a block. But 29.4.2 policy is stricter and retroactive: its mempool and wallet treat every coinbase as needing 6480 confirmations. That is why an old reward can be consensus-valid yet still be rejected by a normal Knots transaction broadcast.