Would it be technically (legally) possible for the Linux kernel developers to create a new license (similar to GPLv2) but different in the sense that hardware manufacturers are prohibited from distributing future versions of the Linux kernel with their product if they do not open source their latest drivers' source code for the device?
There are a few issues.
First, there is no one group that holds all copyrights to the kernel code. Hundreds if not thousands of contributors and corporations, all of which must OK re-licensing the kernel. Given that some are dead, etc. that likely won't happen.
Secondly, it is already a requirement to release via GPLv2 any kernel code or modifications. This means the closest you'll get to a proprietary driver in the kernel is a F/OSS wrapper to a binary blob, much like the NVidia drivers or wireless drivers/firmware using the
Note that on a technical level, the kernel will complain (and loudly) about being tainted with non-free code if you are using a wrapper and non-free binary blob.
The GNU GPL already limits, to the maximum extent possible under copyright law, the ability to include proprietary drivers in the Linux kernel. Kernel drivers already must be licensed under the GNU GPL in order to be distributed within Linux.
The workaround that you are concerned about in asking this question is the practice of a including a "wrapper" kernel driver that is designed to link to or otherwise execute a non-GPL-licensed "binary blob" of code, external to the driver itself. In this case, the legal reality is either that
The binary blob is part of the same work, under copyright law, as the GPL-licensed driver, in which case it is indeed a GPL violation to distribute the blob without source. Such a legal conclusion, if true, would satisfy your requirement perfectly.
The binary blob is a separate work, under copyright law, that is distinct from the wrapper driver that uses it. In this case, the copyright license like the GPL cannot impose requirements on an unrelated copyrighted work.
The GPL's copyleft provisions can successfully operate as they do because new code that enters into combination with a GPL-licensed work becomes part of a derivative work of the GPL'd work. Since the preparation of distribution of derivatives is an exclusive right of the copyright holder, the GPL may limit this activity by regulating how it licenses to downstream users the right to prepare derivatives. By contrast, if the blob is not part of a derivative, then no copyright license terms may impose requirements on it, and it is not possible to construct a copyright license that operates in the way you request.
Thus, it is either the case that the GPL already satisfies your requirements, or no copyright license can do so. (I do not attempt to resolve this disjunction here.)
I suppose it might be possible to draft contract terms that prohibit use of binary blobs, in much the same way that I suppose it may be possible to draft contract terms that impose any arbitrary requirement (e.g., "I'll let you modify and distribute this software but only if you do so while holding your breath underwater"), but I don't know enough about contract law versus copyright licensing to say how this would operate differently from a copyright license in practice. In particular, I'm not sure if, how, or when you would need the downstream user's agreement to the contract terms.