I haven't reviewed your tests, but a couple quick comments: we generally prefer duck typing to the use of isintance or ABCs, but sometimes the latter is better (it's a judgement call).  I haven't done a deep dive in the code you modified, but from the looks of the code quoted in your patch I'd say that doing 'iter(v)' inside the try/except would be the way to find out if one can loop over the object, which appears to be the only aspect of sequenceness the code cares about.

As for coverage, you are right that it is quite possible to get caught up in the statistics.  That said, if you *don't* have domain knowledge, giving us a set of tests to look at and evaluate is better than not having such a set of tests.  Pointing out any tests that you aren't sure about the validity of is helpful in any case.

The overall goal of the test suite is to test the *API* of the library functions.  This is so that alternate implementations can use it as a validation test suite  (Sometimes we have CPython specific tests, in which case we mark them as such).  So testing internal implementation details is not as helpful as testing behavior.  If you find you have to use a "white box" test (one that pokes at the internals as opposed to making an appropriate call to the API), then the code you can't otherwise test becomes suspect and an appropriate subject for another issue ("what is this code for?  I can't get it to trigger.")

Finally, your point about comprehensive tests at least showing up behavior changes is valid.  If you write tests that you aren't sure are "correct behavior", put in an XXX comment to that effect.  If you just have no idea, you can mark a whole block of tests as "this improves coverage, I have no idea if the behavior is valid or not", and we'll either sort it out when we review or commit the tests or just leave the comment in.

Thanks for working on this.