Yes and no. The way it worked before, using "require('minecraft-protocol').createClient()" would "eat" those packets to a certain point (you could still listen to them, but there was a default listener that would take care of all the logic), but using "new require('minecraft-protocol').Client()", you would only have a bareback client without any packet handler by default : you have to go through the login sequence, etc. While not directly useful for your alpha project, I used it in the past to toy with some client-side as well as server-side login ideas. 

With specially-named event, it'd be the same thing, but it'd just make the client.js a bit more verbose (having 6 different checks on the state + packetId "just" to trigger the right event). Also, it is still possible to use the old client.on(packetId) directly, provided you are sure to be in the right state.

```javascript
client.on('state', function(newState) {
  if (newState !== states.PLAY) return;
 client.on(0x02, function(packet) {
    // do stuff
  });
});
```

If you don't wrap a state-check, you'll probably get an error though, because the event will still trigger for login 0x02 packet. That was the original motivation behind the [state, packetId] event name.