Why polling was the default
Token state is independently verifiable, so the simplest correct client is one that asks for a token's current state and checks it. That is easy to reason about and it is what the first SDK shipped.
It is also wasteful. An application watching a few thousand tokens spends most of its requests confirming that nothing has changed.
Subscribing instead
The new surface lets a client subscribe to a set of token identifiers and receive each state transition as it is anchored. Every pushed transition carries the same proof material a polled read would return, so a subscriber verifies exactly what a poller verifies.
A push you cannot verify is a notification. A push you can verify is a read that arrived on time.
Migration
The polling surface is unchanged and is not deprecated. Subscriptions are additive, and an application can mix both: subscribe to the tokens it cares about continuously, and poll on demand for the rest.
Reconnection is the one case worth handling deliberately: on resubscribe, the client receives the current state rather than a replay of missed transitions, so an application that needs the intermediate history should read the token's chain directly.