While diagnosing #12985, which involves the sil_greek_polytonic keyboard, I noticed that certain rules weren't firing when expected. After digging down into things, it appears that Web does not currently handle rules of the following form correctly:

nul ______ + [ key ] > c anything

Rules that are of this form, however, are fine:

nul + [ key ] > c anything

Checking into our repo's history... this has likely been in place since 10.0 and is due to the following sections of code:

• 18.0-alpha:

  • keyman/web/src/engine/js-processor/src/kbdInterface.ts

    Lines 376 to 381 in b4e8912

    	for(var i=0; i < subCache.valContext.length; i++) {
    	if(subCache.valContext[i] == '\ufffe') {
    	subCache.valContext.splice(0, 1);
    	subCache.deadContext.splice(0, 1);
    	}
    	}

• 10.0:
  • See [KeymanWeb] The Deadkey Rework #613:

  • keyman/web/source/kmwcallback.ts

    Lines 389 to 394 in c5f120e

    	for(var i=0; i < subCache.valContext.length; i++) {
    	if(subCache[i] == '\ufffe') {
    	subCache.valContext.splice(0, 1);
    	subCache.deadContext.splice(0, 1);
    	}
    	}

In both cases, should a context containing non-nul components have slots containing nul at their head... it just... chops it off, causing a misalignment for the method designed to match that context in a rule. I'm the original author of the block, to be sure... but at this point, I have no idea why it's there. To be safe, I ran our existing unit test suite against a version of Web with this block removed (no other changes)... and all the unit tests passed. Why is it there? Note that this approach was enough to allow for an easy repro of #12985 as well.

Not yet done - adding more unit tests to validate rules of the first form listed above; we want a clear "before and after" picture for this and any related changes.