But that's not to say that the key check you introduced earlier is bad; maybe it's worth keeping as an additional test?

One argument I'd make for not keeping it, is it does mean the test will need to be updated as we update the options bag over time. I was wondering if this is needed, given what we're really testing is the serialization.

test_repr tests the serialization, so we can leave that as it now stands after your changes.

The set comparison you introduced earlier and then removed would be an additional test on the options object. I generally agree we don't want to have to make a lot of dependent manual changes when something fundamental changes. However, if we don't check anywhere else for the keys that are in this bag, this would be a good signal in case something accidentally gets deleted. I don't know whether we test these keys elsewhere. I assume new options don't get added all that frequently? (real question; I don't know)

So I could go either way, as I'm not super familiar with how these options are used or tested. But my inclination is to add back (in a separate test) the set-based key check you had earlier, precisely as a safequard against accidental deletion. But I'm certainly not fixated on this, and am happy to hear reasons not to.@parthea , WDYT?

The set comparison you introduced earlier and then removed would be an additional test on the options object.

Okay, I've added it back.