Hi Ben

You've definitely got a point. When you do
    seen.add(key)
it's sometimes important to know if this changes 'seen'.

Here's a one-liner that does what you want:
    key in seen or seen.add(key)

It's a bit obscure, and perhaps a bit too much https://en.wikipedia.org/wiki/Code_golf. So here's a worked example.

    >>> seen = set() 
    >>> 0 in seen or seen.add(0)
    >>> 0 in seen or seen.add(0)
    True

The first time '0 in seen' is False, so the OR part 'seen.add(0)' is executed. As you and others have said, seen.add(key) always return None. (The REPL does not echo the expression value if it is None.)

The second time '0 in seen' is True, so the OR part is not done, and the value of the expression is True.

If you want, in your own code you can subclass set to provide the behaviour you think is missing. Or just write a utility function. I think that would in practice be better.

    >>> def in_or_add(s, key):
    ...    return key in s or s.add(key) or False

    >>> seen = set()
    >>> in_or_add(seen, 0)
    False
    >>> in_or_add(seen, 0)
    True

An aside. Your proposal is:
value. set.add would return True if the item was already in the set prior to insertion, and False otherwise.

This allows you to simplify your code example. But I find the semantics a bit odd. If set.add(key) were to return a boolean, I'd expect it to be True if the item genuinely was added. But your semantics are the other way around.

My proposal of in_or_add and your revision of set.add both have the same semantics. I think that is clear. But they have different names. If enough people use a utility function such as in_or_add(s, key), then that makes a good case for adding it as a set method.

Two final points. While processing the 'not key in seen' branch, an exception might occur. Sometimes it's better to add the key to 'seen' once all the associated processing is complete. (An exception that leaves the system in an inconsistent state can cause problems later.) The second point is that I'm not confident about 'in_or_add' as a name for the method.

Once again, thank you for your interesting idea.
-- 
Jonathan