I think it's intentional behavior seems to be minor though.

At a glance, I assume that a.set(b) should return items in a. But I found out the implementation always return items in smaller set.

There is no issue for common case, but custom class can make a trouble. So, I think additional information of return value is helpful.

To clarify, are you referring to this behaviour?

>>> a = {1, 2, 3}
>>> b = {1.0, 4.0}
>>> a.intersection(b)  # expect {1}
{1.0}

I'd personally expect this to be implementation-dependent: since for set operations you usually only care about objects up to equality, it would be a bit unusual to care whether you get {1} or {1.0} in the above situation, and I'd say the implementation should be free to do whatever's convenient. Making documented guarantees would unnecessarily constrain other implementations.

I suppose one could document the *lack* of a guarantee here ...

The implementation detail is not documented because it is not guaranteed.  The behavior has changed over time and other implementation are allowed to do something different.  For example, collections.abc.Set.__and__ has different behavior.

Ok, I got a point of implementation-dependent things. Thank you for comments.