I can reproduce and confirm Issue 1, which is based on a (wrongly performed) optimization in the Format value action. I'll fix that to the next release.
If you're interested in the details: I'm comparing the existing and new values and don't change anything, if they're identical. However, I was only comparing the first value, which leaves the complete field untouched in case of $meta(field,0).
Issue 2 is a little bit different: it currently leaves the field untouched if you're using %field% as format string. This is only due to the erroneous check described above. Why? Because %field% always returns the first value of field. So after Issue 1 is fixed, both cases from your example in Issue 2 should return Arnold.
A meta comment: you can wrap strings containing backslashes in backticks ` so that they're formatted as preformatted text, e.g., Arnold\\Bruce\\Cedric.
Thanks for the details, they made me realize that if the receiving field is a multivalue field too, and value 0 is identical in both fields, then this bug will occur regardless. So the format string doesn't need to refer to its own field as I concluded.