We are still working on memory improvements. Apart from that there is no feature left for version 5. I expect that the first release will be in a few months.

The abstractions are reduced in version 4 to reduce breaking changes. Version 3 had a lot of abstractions but unfortunately it leads to lots of breaking changes especially when new features are added. Sometimes there were just a few constructors changed or method signatures, but people start complaining because they often have to change their code just to get the benefits of security fixes etc.

Apart from that my personal recommendation is to always create your own abstractions so that you can exchange the library with a another one. This makes it also easier to change from another library to this one. I usually avoid that code (and tests) is heavily depending on any library (apart from .NET Framework).

But I agree that the limitations in the early versions of version 4 are too much. So, we readded some interfaces and public stuff again.
Please let me know what abstractions you are missing (in version 5). Maybe we find a way to fulfill both needs.

Thank you for your reply. I can certainly understand that with interfaces comes contracts and that these can change... there are many ways to solve it though and with recent C# many more ways. In any case, an example of a problem we are facing is thatMqttClientConnectResult is impossible to use in testing since it is sealed and only internally setable. Hence, this cannot be created in any real way.

Another issue is the asyncevents that returnTask, which are a bit weird in .NET givenevents can have multiple handlers and hence it has been a long time recommendation to never have return values on those. The issue here is this makes them harder to "mock". There are ways around it, but the design is a bit outside normal. Although, this pattern is seen in other libraries even ones from MS.