It does look as if an umlaut character is giving an off-by-one error. To replicate your report I took these steps (test file attached at end). To test I took this string from your screen-grab:
I made that the $Text of a note and ran this stamp on it:
$MyNumber = $Text.find("x");
$MyString = $Text.substr($MyNumber,1);
For the above string $MyNumber is
42 and $MyString is
x. Now, in a new note, I laced an amended (sorry if ungrammatically!) a ‘u’ to a ‘ü’, as in:
Re-running the stamp on the revised $Text, $MyNumber is now
43 (wrong!) and $MyString is now
-. So changing one character to an accented character is causing a mis-report—from the user’s perspective—of the
.find(string) string argument if the accented character comes before the
.find(string) string .
Another check mores the accent after the searched string (again, apologies for non-grammatical usage), undoing the ‘ü’ change but altering ‘o’ to ‘ö’ later in the the string.:
Re-running the stamp on the revised $Text, $MyNumber returns to
42 (correct!) and $MyString is
x. The latter reinforces the observation that adding an accented character. Indeed, as in the test file, adding two accented characters before string results in a $MyNumber of 44.
See: find-string-test.tbx (84.3 KB)
Whilst, that can’t easily be fixed, we might route around it for the wider context. What custom Explode delimiter are you trying to define? Here to a simple text file might help us fellow users help you.