The MTP repair shipped in 0.5.37 fired on a real model during a capability
sweep and made the failure worse. llama.cpp validates per-layer metadata arrays
against block_count, and a metadata override can only carry a scalar — bool,
int, float or str — so there is no way to shorten the array to match. Correcting
the count therefore does not fix the load, it only changes which error it fails
with:

    before   missing tensor 'blk.64.attn_norm.weight'
    after    key qwen35.attention.recurrent_layers has wrong array length;
             expected 64, got 65

The first message names the real problem. The second sends the reader looking
for a corrupt array. A repair that only changes which error you get is not a
repair, so it now declines when any per-layer array is present and the honest
message stands.

Declining silently would be its own trap — the shape still looks repairable from
outside — so unrepairable_reason() explains it before llama.cpp speaks: which
array pins the count, that an override cannot carry a shorter one, and the two
ways out (a quant that keeps its NextN block, or a llama.cpp that derives the
layer count from nextn_predict_layers).

"Per-layer" means length EQUAL to block_count, so a tokenizer's 248,320-entry
token list does not veto a repair it has nothing to do with. The test fixture can
now write array-valued metadata, which is what it would have taken to catch this
before shipping rather than from a live sweep.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC