Solved ... kind off The line `c = bufx[k]ยดยด above was followed by ``key[j] = c`
(which already was a split for debugging and was originally `` key[j] = bufx[start + j]``) and `key` was a `newStringOfCap(64)` var. @Araq whom I want to thank and laud for his friendly help in our chat for providing useful hints and tips drove me to furiously testing/looking at my `bufx` array and to also try to heap allocate it. What this lead to was finding the real culprit, namely `key` \- which makes this whole thing even weirder because the compiler was unhappy about the wrong array (bufx instead of key). The solution (well, rather a work around) was to _stack_ allocate the string `key` (Don't ask me for the reason; that's something probably only true Nim wizards could find out). Once I had done that everything worked fine, even with index checking turned on. However, I want to clearly excuse the Nim compiler. The whole stuff I talked about here got fed into _heavily inlined_ and complex code and I've seen way more mature (e.g. C and Pascal) compilers choke on way less demanding code. Nim is still just v. 19.x and I found it all in all to be quite reliable and smart. While it's not urgent the Nim devs might sometimes want to have a closer look at the array/openarray/string stuff (alloc and checks).
