I think I've come across it before, but tbh as @FindRegEx only gives you the start of the match but not the length of the match or the match itself i rarely use it. Positive lookahead and look behind work fine in @ReplaceRegEx which is rather curious

Thanks for you answer. Yes, in a way @FindRegEx is similar to @FindString, in that it gives the index of the first match. It would be handy to have a string function similar to the StringSearcher that actually returns the match itself. Well I did some testing as you can see in my updated question. It is the @FindRegex that can't handle lookbehind. And the StringReplacer is not good at lookaround at all, compared to the @ReplaceRegEx.

@danielkroon​  Thanks to @danielkroon​ for putting together such a comprehensive example workspace.

For StringReplacer, the Mode must be set to Replace Regular Expression. I also found that adding a Capture Group in the expression helps guide the replacement in Stringreplacer so (?<=px)(\\d) instead of (?<=px)\\d

That does leave @FindRegEx() that does not behave the same as StringSearcher for the lookbehind. My research indicates lookbehind isn't always supported, so we'll try and find out why FME has the different behaviour.

Revised workspace attached (FME 2020.2):

Thank you @Mark Stoakes​  for digging into this!

As you mention, it was a simple mistake in my test workspace that put shadow over StringReplacer.

It proves the importance of peer review.

Interesting with the capture groups, however I can't see any difference with or whiteout them in the StringReplacer, which works with mode set to "Replace Regular Expression".

I'm very happy with the answer, since regex lookaround can be very handy and powerful!