Added Area-Library, Triaged labels.

Returning information that is otherwise available is a two-edged sword.
It may make some things slightly simpler, but it is also an overhead in the cases where the information isn't needed.
And it risks not being the thing you actually need. Something that makes perfect sense in one case might not make sense in another, depending on what your collection represents. We could return a boolean that was true if something changed, and false if not (as we do for remove), but if you need the count, that is just unusable overhead.

In many cases, encapsulating the collection in a more domain related class will allow you to do the thing that makes sense, and it doesn't matter that you use a few more lines in the abstraction if it makes the use of it simple. It does matter to use a few more lines in the basic collection, because it hits every use of it.

In this case, the number of elements removed is reflected in the length of the container, so you can do something like:
  if (set.length > (set..retainAll(something)).length) // something changed
or
  if (set.length - (set..removeAll(something)).length == something.length) {
    // removed all
  }
It does look a little confusing, and I can see the wish for shorter code, but I don't have any current plans for it.

Removed Type-Defect, Priority-Unassigned labels.
Added Type-Enhancement, Priority-Low labels.

This comment was originally written by @xximranxx

Yes, fully agreed that overhead should be avoided in basic collection.

Actually, in my specific use-case, I would only need the boolean return whether anything was affected or not.

If returning that information does not cost overhead, I think it would be a useful change in code.

Thanks