Introducing an additional message exchange into the authentication sequence would allow us to support multiple authentication schemes and negotiation of SASL mechanisms.
The current AUTHENTICATE message sent from Client to Server includes the java classname of the configured IAuthenticator. This could be superceded by a new message which lists the SASL mechanisms supported by the server. The client would then respond with a new message which indicates it's choice of mechanism. This would allow the server to support multiple mechanisms, for example enabling both PLAIN for username/password authentication and EXTERNAL for a mechanism for extracting credentials from SSL certificates* (see the example in RFC-4422). Furthermore, the server could tailor the list of supported mechanisms on a per-connection basis, e.g. only offering certificate based auth to encrypted clients.
The client's response should include the selected mechanism and any initial response data. This is mechanism-specific; the PLAIN mechanism consists of a single round in which the client sends encoded credentials as the initial response data and the server response indicates either success or failure with no futher challenges required.
From a protocol perspective, after the mechanism negotiation the exchange would continue as in protocol v4, with one or more rounds of AUTH_CHALLENGE and AUTH_RESPONSE messages, terminated by an AUTH_SUCCESS sent from Server to Client upon successful authentication or an ERROR on auth failure.
XMPP performs mechanism negotiation in this way, RFC-3920 includes a good overview.
* Note: this would require some a priori agreement between client and server over the implementation of the EXTERNAL mechanism.