The latest code from yesterday works with publishing/subscribing in single threaded mode. I've run it on Linux, but not yet in mbed.

I have some reservations about having one callback (messageHandler) per subscription, which are:

• We have to record the callback info per subscription which means more storage. The code has a parameter to limit the number of subscriptions allowed because of this. We would have to deny any subscription requests which would cause this limit to be exceeded.
• It is possible on some servers to be able to get messages which have not been subscribed to. To handle this case, we will need a default message handler which is not associated with any particular subscription.
• If/when we add a persistence capability (allowing an MQTT client class to be recreated with its previous state), we might have existing subscriptions from the previous session. If we don't set callbacks for each of these, we would again need a default message handler callback.
• If wildcard topics are used and more than one subscription matches the topic in the incoming message, we will have to deliver the message to more than one messageHandler, thereby effectively duplicating the message.

We can continue with this approach, as long as we recognise the limitations.

The costs (more storage) seems worth the benefit of having leaner, more precise application code. Is the limitation regarding persistence a volatile memory problem?

Sort of :-) It's kinda hard to reinstantiate callbacks in a new program instance, so you have to rely on the application program to do it. And it might not, unless we enforce it in the API somehow.