It seems as if you have not set the "Set State" option on the Regular Expression statement. As such the state is not being modified. On various statements the "Set State" is optional as earlier incarnations did not set the state. In order to retain compatibility, the state setting is optional.

I ran the following:

Set named variable 'source' to "abc test def test"
Set named variable 'exp' to "test"
Set named variable 'rep' to "XXX"
Find first match for regular expression "\<exp>" in named variable 'source', replace with "\<rep>" to named variable 'result', case insensitive, set state
Dump named variables. Show Action Test State

and get the following output:

Action test state = true

Named Variables

exp = test
rep = XXX
result = abc·XXX·def·test
source = abc·test·def·test

It might be a good idea to enable the "Set State" option on new statements. I'll add it to the next release.

Okay I see what's going on. I have to figure out a way around the issue. From the documentation:

All regular expression meta characters which may be inserted by the substitution will be properly escaped.

That means the substituted text is coerced to be a literal. However in your case you want the substituted text to be a regexp. It's failing because the literal pattern is not being matched.

I have to come up with a way of handling both cases. I guess most people have been using and wanting the literal insertion as it is a convenient means of escaping the regexp meta characters.

In order not to break anything I'll have to introduce a new "don't escape" sequence to introduce at the start of the expression to tell me not to regexp-escape the contents of the named variable.

I'll get back to you with my solution.

This seems to work perfectly and your response time is unbelievable. I do see now why you may think it's not terribly aesthetic, however, as it's a special-case escape sequence just for this one Action field...

I guess it all hinges upon whether the \E sequence is necessary. My initial feeling is that an invocation of the Regular Expression Action will be one of two types: either a 'hard-core' regular expression with escape sequences, etc., as above in named variable 'PrestoPattern', or a more vanilla one like that in your first reply above. If that is indeed the case, then it may be more elegant to just supply a check box against the Regular expression input box: Literal either On or Off for the entire Action.

But I personally quite like the option of \E...

Users need to be aware that with this new capability, backslashes themselves must be escaped in variables that supply the regular expression, so an alternative for 'PrestoPattern' above is now "^(\\d{2}) - (.*?) - (.*?) - (.*?)$" (\d is shorthand for any digit).

Many thanks for this fast and productive response!

Inserting "\d" in the regex variable substitutes the date... This behaviour must be overridden so the regular expression sees "\d". To do that, you need to escape the "\" -> "\\d".