analyze-string-090b and analyze-string-092 are reporting an error XTDE1150: The regular expression must not be one that matches a zero-length string. This error no longer exists in 3.0, but the generated bytecode is still testing for it.
The interpreted code checks for the error too, but only if dialect="XP20" which is never true.
The reason it doesn't fail in the non-export case is that the regular expression is known and compiled at stylesheet compile time, so the generated bytecode does not need to compile it or check it. So there's a root cause of the problem here, namely that with reloaded code, the regex isn't being precompiled. (However, 9.9 introduced regex caching, so this doesn't matter as much as it once did.)
I have removed the error check from both the interpreted and compiled path and the test cases are now working both with and without export.
But this leaves the question why the regex is not being precompiled.
For system functions like matches(), the package loader has a completion action which calls SystemFunction.fixArguments() which enables the function to do any optimizations based on the fact that some arguments are fixed. However, Matches (and its superclass RegexFunction) do not implement this method. Instead they have a method tryToBindRegularExpression(), which is called during function call creation (SystemFunction.makeFunctionCall()) and therefore happens automatically during package loading.
To get the same effect with analyze-string we should invoke the "precompute regex" functionality of the AnalyzeString expression immediately after creating the expression. DONE.
.