> Do you want to submit a PR for this?

Sure. Do you think the code I proposed would be suitable?

> * The current logic matches the logic before the warning was added.
> * The proposed logic matches what the code will do after the
>   deprecation period (it will only check for non-sequences).

Yes, that was my basis for it as it seemed sensible, but you're right that it's a bit of a behavioural change as you note:

> * There is some value in the warning in that it lets you know an
>   inefficient code path is being used (i.e. the conversion to a tuple).
> * The proposed logic doesn't just change the warning, it changes
>   what actually happens to the data.  IMO the change is for the
>   better, but it is a behavior change and could potentially cause
>   a failure in someone's code.

Aye, and also I guess the "sequence" implementation of the input collection might be less efficient than one-shot converting to a set and sampling from the set.

> * The case of an object that is both a sequence and a set is
>   likely very rare.

Chances are you're right, but it's what got me to stumble upon it ($dayjob makes significant use of a "unique list / ordered set" smart-ish collection, that collection was actually registered against Set and Sequence specifically because Python 3's random.sample typechecks those, we registered against both as the collection technically implements both interfaces so that seemed like a good idea at the time).