Networking – Reset Router – Old SSID Still Showing Up Even After Forgetting the Network

1. No.

2. It has no benefit, so just don't do it. But it can make it harder for clients to find the access point and it can make it impossible for clients to pick the best access point (if you have more than one).

3. That's possible if the access point isn't locked on one frequency and is set to choose a frequency automatically. It's not that likely if the AP is set to one channel.

Wi-Fi clients can't tell, before they connect, what wired network a given AP will connect them to.

So if you have two APs publishing the same SSID with the same security type and password (or no security at all), clients will roam to it thinking it's part of the same underlying network. If the two APs actually connect to two different underlying IP subnets, this will break all the higher-level connections or traffic flows (SSH sessions, TCP downloads, video streams, mounted file servers, etc.) that the client had in progress.

In a worst-case scenario that's all too common, if both APs are acting as NAT gateways and using the same private IP subnet, a poorly-written client may not even realize it has switched networks, and may keep sending its Internet traffic to the MAC address of the old AP, not the new AP, until the ARP entry for the router times out. Apple's client devices (OS X and iOS) do something called DNAv4 ("Detecting Network Attachment in IPv4": RFC 4436) to make sure this doesn't happen to them. Whenever a Mac or iOS device's Wi-Fi interface says it has roamed from one AP to another, the network stack and DHCP client double-check that this is really the same network, in order to more quickly re-establish proper connectivity. I called this out in my answer to "How can I get the same SSID for multiple access points?".

By the way, I need to point out that some other Answers to your question are spreading a false myth. Most client implementations WILL NOT look at all "saved" SSIDs for roaming if they're still attached to an AP for one SSID. Most client implementations will stick on the current SSID, and only try to roam within APs of the current SSID, unless the client becomes completely disconnected from the current SSID. The (incorrect) behavior the other Answers describe would completely suck, because let's say you live in the apartment above a Starbucks, and your AP is in the living room, but back in the bedroom, the Starbucks AP is stronger than your own AP. You don't want your client to roam to the Starbucks AP just because it's stronger.

Switching to other "saved" SSIDs only happens if you're completely off the network, such as when your AP is completely out of range (or off or crashed), or on boot, or possibly wake-from-sleep (but I argue that even wake-from-sleep algorithms should make an attempt to get back on the last SSID they were on, especially after a short sleep, in order to provide the best network service continuity).

Edited to add: I should point out that neither the IEEE 802.11 standards nor the Wi-Fi Alliance's specifications and test/certification programs specify the exact roaming and "preferred/saved" network-joining behavior of 802.11/Wi-Fi clients. I've described the behaviors of clients I'm most familiar with (Apple clients), but it's entirely possible that there are poorly-implemented clients out there that do dumb things.