The problem with this is that v2 by definition does not provide the v1 interface, or there would be no reason to bump up the major version number.
Using the trick, the last v1 package is a facade that constructs the old interface using the new package. To provide equivalent functionality, you basically have to do the same thing.
OK then if you want to keep the v1 interface exactly then you have to build a facade yourself. I don't think most libraries are capable of supporting that use case because of their semantic structure. Instead of employing a bunch of tricks to avoid fixing a couple of functions (the case where a facade makes sense), you should just fix the callers. That might not be easy for packages that are independently published (for example pypi or cargo packages) but it is possible in many package managers that have central teams of maintainers.
The whole thing is sus. If widget=2 can work as a drop-in replacement (non-breaking) for widget=1, then why the version bump in the first place?
But in the real world there are times when major versions are bumped without breaking changes. E.g. a bunch of crates maintained as part of a single project with a uniform versioning scheme.
I think now there must be some kind of adapter code, even if auto-generated, that is a facade from v1 to v2. You can essentially use that to release a new v1 minor revision that depends on v2 for its implementation. But yeah the whole thing sounds sus, not easily applicable to other languages (where does this adapter code come from and how does it coexist with v2?), and like a bad practice even when it can work. You should really just migrate everyone to the new version instead of patching together something to handle stubborn users of the old version.
Using the trick, the last v1 package is a facade that constructs the old interface using the new package. To provide equivalent functionality, you basically have to do the same thing.