Haunted by ancient history

No, you didn't quite understand my cooking analogy I think. iwconfig requires that the kernel keep track of the previously configured settings, and allows you to modify them later. With nl80211, the kernel will forget everything it did when it disconnects.

Say you have a network on channel 11 (2462 MHz) called "my-network".

With iwconfig you can now say

iwconfig wlan0 essid "my-network"
(it connects to your network)
iwconfig wlan0 freq 2412
(it disconnects, and fails to reconnect since there's no network on channel 1)
iwconfig wlan0 freq 2462
(it connects again to the original network)

with iw/nl80211 you don't have this option.

You can say
iw wlan0 connect "my-network"
(and it will connect)

or
iw wlan0 connect "my-network" 2412
(and it will fail to connect)

or
iw wlan0 connect "my-network" 2462
(and it will connect again)

But the kernel will not remember [1], upon disconnection, that you had previously wanted some SSID. To emulate it completely, you'd thus have to store state somewhere (filesystem? shared memory? ...?) which gets complex really quickly.

This is really intentional though - having the kernel keep state means that the kernel needs to guess when it should start doing something. This is like my cooking analogy, there's no way for the kernel to know when it should start cooking. [2]

As far as site survey is concerned (iwlist scan) - there's another interesting quirk here: if you have too many APs in the environment, iwlist/wext will stop working and report only errors and no networks at all. This is an inherent design flaw that comes from having to fit the entire list of APs into a single buffer that's limited to 64KiB, and no way to fetch the list incrementally (like nl80211 which uses netlink dump functionality). People have run into this in big deployments (usually when there's also a lot of data in the beacons which eats up the buffer quickly.)

I don't believe that there's much that is possible with iwconfig/iwlist that you cannot do with iw at all, other than some esoteric settings like modifying sensitivity that no modern hardware supports anyway. I certainly haven't used iw* in many years.

[1] and that's really intentional, if the kernel were to remember some data you get into the strange situations where to switch from one network to the other the kernel might try to connect to the old network on the new channel, or the new network on the old channel, or similar. With open networks this really isn't a problem, but with encrypted or potentially rogue networks you really don't want to even attempt to connect to a new network with half of the old configuration. Forcing userspace to commit the entire needed configuration at once easily side-steps that issue and made the whole mechanism far easier to extend to new spec updates as well.

[2] Jean actually invented SIOCSIWCOMMIT for this purpose, which in theory would have allowed you to set all the parameters and then commit them all together. However, that came too late - since it wasn't designed into the API from the beginning there was no way for the kernel to require it since that would also have broken older userspace.

Also, the Right Thing™ (and I'm a little surprised the Windows laptop doesn't do this of its own accord unless you've missed part of the story) is that you'd leave the WiFi up in your scenario, and the IP stack will choose the Cat5 (or whatever) for all new connections while continuing to handle old connections seamlessly on the WiFi.

Almost twenty years ago we demonstrated running VoIP through this scenario (moving from a wireless to a wired network) with Mobile IPv6. That has yet to become a commonplace application, but it was taken as read that if you began a _new_ call it would move to the better connection with no additional technology, our work was on handling an _in progress_ call correctly.