It's just an opinion, but i'm against it. It's not an expected behavior. If a setX(getX() + Y) is inconvenient, i would recommend to add something like "append".

What do you mean with expected behavior? My expected behavior is that setting additional data does not replace existing data carelessly, which is the main issue with this method - especially when it comes to ADD more values to an element's class attribute. The fix not only catches this issue but also checks for duplicates. The latter would potentially get created if you append new values to this attribute.
To prevent this duplication either there are two scenarios:

a) the developer must read the attribute first, prepare the value (remove any dupes) and then set the new value
b) the field class method makes this job, which makes the developer's life easier

I suppose you haven't had to add new class attributes to form fields on that often yet, have you? :-)

The expected behavior of set(x, y) is setting x to y. I'm not a native speaker, but set implies a single task no matter the past. I'm not against a feature for accessing the attributes in a more convenient way, but the current solution seems not right to my. But of course, that's only an opinion. In a real OOP world you would need something like Field->getAttribute()->add('foobar').

I agree with @nueckman

And I am sure someone already use setFieldAttribute() to replace existing attribute, I seen somewhere in CMS it used for override existing attribute in the form field(s).

this pull will make b/c issue from my point of view

@Fedik it's a new paramater, so there will be no b/c issues in a coding way (at least if you haven't override the method). But i'm still against it ;)

I tend to agree with @nueckman that the setMethod is for setting a complete new value. Look at other classes we do the same there. I would be more inclined to have an addFieldAttribute() method instead, doing the same thing but with a clear task.

Don't know where this PR is...

Just a note:
In library, setField already have a $replace option.
public function setField(SimpleXMLElement $element, $group = null, $replace = true)

So could make sense to have the same for setFieldAttribute ?
public function setFieldAttribute($name, $attribute, $value, $group = null)

This option could be really useful in some cases (i see one currently in my own extension!) and by looking at code, no B/C issue.
I will test this PR soon...

Just for the record: I'm still not convinced ;) The $replace argument in setField is more like a $force. But this PR wants to add the ability to append something to the current value.

And what about values that are comma separated, semicolon separated and so on?
You don't know how values look like. Space separated is one special case of lots of.
Should be solved in another way than this PR does (if feature really needed).

The setFieldAttribute should only set values, if we want to append values there should be an aptly named function for that. A pull request with that feature would be needed. Closing this pull request for that reason. Thank you all for your contribution.