I have no idea whether a flag on zip() or a function in itertools would get MORE USE.  I *ABSOLUTELY* think it is an anti-goal to get more use for its own sake though.

I'm +1 on a new function in itertools, maybe +0 or maybe -0 on a flag.  But I only want APPROPRIATE USE in any case.  The API conventions of Python in general very strongly favor a new function.  Yes, not everything in Python naming is consistent, and counter examples for any idea can surely be found.  But it just is a lot less surprising to users to follow the predominant pattern that zip_longest(), for example, follows.

The real point, to me, is that users who use itertools.zip_strict() will use it for exactly the reason that they want that semantics. In contrast, a flag for `strict` or `truncate` or `equal` or whatever is a LOT more likely to be used in the "just in case" code where the programmer has not thought carefully about the semantics they want.  The sky isn't falling, I certainly don't think everyone, nor even most developers, would use the flag wrong.  But a separate function just provides a better, more consistent, API.

I don't think anyone in the huge discussion of the walrus operator, for example, tried to make the case that the goal should be encouraging it to be used AS MUCH AS POSSIBLE.  Nor likewise for any other new feature.  A feature should be used *where appropriate*, and the design should not vacantly simply try to make it more common.

--
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.