I'll test this later but there are some possible issues:

1. .disconnect() with reconnecting = false will update the voice state and disconnect the client, this is only bad because things like voice server updates (changing the voice region) would also give a 4014, which we wouldn't want to full disconnect from and would rather wait for the next VOICE_SERVER_UPDATE event. On a 4014, data.endpoint would be set to null which would signal to .connect that it should wait for an event:

if (!data.endpoint) {
  return; // Endpoint null, wait next update.
}

2. VOICE_STATE_UPDATEs would already update/disconnect the connection if the client was kicked or if the channel was removed.
3. A failed reconnect would properly disconnect the client if it came to it, emitting the disconnect event.

I've tried kicking the client from a VC and it seemed to disconnect just fine because of the VOICE_STATE_UPDATE, maybe there should be a separate timeout for that update waiting.

I didn't read that essay, but ideally the only change here would be just to disconnect, existing functions shouldn't change unless there is a clear benefit or if it is absolutely necessary nvm read context and understand this a bit more now

a 4014 here in this case means you shouldn't reconnect to that websocket. reconnecting to the voice channel on the other hand is an entirely different question. Assuming the disconnect was not intentional client side, we should reconnect to the voice channel on a new websocket

I see. It seems that I misunderstood the meaning of reconnecting here. Will close this PR for better solution.