I introduced MQTTPacket_readnb() to work on a bare metal system, no OS, perhaps no need for a shared library. Since the function is non-blocking there is the need to have a state outside of it.
Just for the sake of learning, what is your current issue that is not covered by the other functions ?

This particular Linux client is connected to two separate server instances, which is a bit obtuse, but that's how it works out. This probably isn't the right client library for that scenario, but we're already using it embedded so it was easy to modify. I use a derived version of MQTTTransport which stores mbedtls contexts.

The whole library assumes a single connection... even my introduced nb functions use a static (at the transport samples). I guess yours is not a very common connection scenario, I myself would expect an embedded client to connect to one server. Anyway, I just dropped by being parental on my function ;^) and I guess adding DDLExport does not introduce any extra overhead for the rest of us.
You could go ahead and submit a pull request if you like, this way the admins can just merge it if they approve it.