I would be opposed to solving the problem this way. I disagree with the sentiment that elementsEqual is uncommon. I find myself comparing different sequence types frequently – it's very useful when testing a new type of sequence you just wrote, for example – and believe we need such a method in the standard library (though I'm pretty flexible on what it is called; my concern with this proposal is that the renaming isn't sufficiently better to justify the high bar for a rename).
As you point out, the logic for elementsEqual is deceptively tricky, and as such, even if we did add a paddedZip, there would be users that miss the issue with just using zip and do that instead – easily as bad a source of bugs as the Set problem that kicked all this off IMO. If equalElements didn't already exist, it would easily qualify for inclusion in the std lib on the grounds of commonality, readability, and difficulty of implementation, even if we did bikeshed ourselves to death trying to name it :)
Additionally, with elementsEqual being an actual method in the std lib, at least we have documentation of it where we can put the warning that you need to be sure not to use it on Set, unlike the composed alternative.
p.s. paddedZip would make a great proposal – though I'd prefer a name that started with zip. Python calls it zip_longest.