Conflict with OptimizePress, nested serialized data

Greetings,

It appears there might be a bug with Better Search Replace (and other search-replace plugins, FWIW) when dealing with postmeta fields created by OptimizePress. OptimizePress nests PHP serialized data (in the most braindead way possible, incidentally), so a typical field in postmeta might have meta_value that looks like:

s:45:"a:2:{s:7:"enabled";s:1:"N";s:3:"url";s:0:"";}";
s:64:"a:1:{i:0;a:2:{s:8:"position";s:6:"header";s:6:"script";s:0:"";}}";
s:51:"a:2:{s:4:"type";s:9:"marketing";s:3:"dir";s:1:"1";}";

etc. When Better Search Replace runs to convert that data (e.g., in a move from https:// to https://) it converts ALL matching lines to:

s:1:"1";

Clearly that’s not great, and all hell breaks loose on OptimizePress-generated pages.

It looks like BSR should be able to handle this, in the recursive_unserialize_replace() function, but something about it doesn’t seem to be working here.