So, as I get from this thread, current patch brings these function very close to Oracle behavior. The only divergence found yet is related to handling of unmatched tails of input strings (Oracle throws an error while we swallow that silently) [1]. But this issue can be be addressed by a separate patch.
Patch seems to be in a pretty good shape. So, the question is whether there is a consensus that we want a backward-incompatible behavior change, which this patch does.
My personal opinion is +1 for committing this, because I see that this patch takes a lot of community efforts on discussion, coding, review etc. All these efforts give a substantial result in a patch, which makes behavior more Oracle-compatible and (IMHO) more clear.
However, in this thread other opinions were expressed. In particular, David G. Johnston expressed opinion that we shouldn't change behavior of existing functions, alternatively we could introduce new functions with new behavior. However, I see David doesn't participate this thread for a quite long time.
Been lurking about...I'm still of the opinion that this capability should exist in PostgreSQL as "our" function and not just as an Oracle compatibility.
That said the thing I'm most curious to read is the release note entry that would go along with this change that informs users what will be changing: silently, visibly, or otherwise. Knowing how much we (don't) diverge from our chosen "standard" after making this change is important but the change in behavior from current is, IMO, more important in deciding whether this particular change is worth making.
My re-read of the thread the other day left me with a feeling of contentment that this was an acceptable change but I also get the feeling like I'm missing the downside trade-off too...I was hoping your review would help in that regard but as it did not speak to specific incompatibilities it has not.