Now I know why it did not completely work initially after back-porting - I had a bit different variant of TclGetNamespaceForQualName (got amended a year later)...<br/>Now it is fully back-ported and new tests added (see namespace-52.14), so it'd always work for a not simple command too (<code>::A::B::C::cmd</code> -> <code>::A::B</code> with unknown, <code>C::cmd</code> is to search, even if <code>::A::B::C</code> is not there, however also if <code>::A::B::C</code> exists, but has no unknown handler.

@Jan<br/>
<i>> I'm +1 merging this to 8.6 and up, considering it a bug-fix for a corner-case which was not considered before. I don't see any negative impact.</i>

Although I also not believe it'd have any negative impact, I must admit I see one compat thing, so it should at least get a release note (as well as a documentation enhancement), explaining a precedence now - "deepest NS with unknown-handler always wins (regardless from where exactly it was executed)".<br/>
For instance in case of 2 nested NS with handlers (<code>::A::B</code> and <code>::A::B::C</code>), for the call:<br/>
<code>namespace eval ::A::B:: { C::cmd }</code><br/>
it'd invoke handler of <code>::A::B::C</code>, where previously it'd rather invoke <code>::A::B</code> (since the first was not implemented yet).