This has been hard, because for some reason, in remote debugging, I can't step or continue once I've hit a breakpoint. Anyway, I've gotten through to the suspicious behavior by stepping through the assembly on the device. The weird stuff happens in YARR-generated code, so there's no symbols there anyway.
Findings: The YARR engine attempts to use the "ldrh" instruction to do unaligned halfword loads. The generated code does this to compare two characters at a time (to match the "AT" part). Apparently, my device's CPU (ARM926EJ-S, I believe) just ignores the 1's bit of the address, so that it always loads aligned halfwords. Thus, for the test case, it gets "ea" at offset 0, "ea" again at offset 1, and "t-" at offset 2. That explains why "eeat-" matches. In further experiments, "eeeat-" doesn't match, and "eeeeat-" matches. Does the "Linux debian-armel 2.6.32-5-versatile #1 Wed Jan 12 23:05:11 UTC 2011 armv5tejl GNU/Linux" allow unaligned "ldrh" or something?