Some thoughts on this:

1. LSS messages are usually very rare on a CANopen bus.
2. The library might be used as part of a commissioning or test equipment, where LSS is one of the central elements needed. Even if just listening in such a scenario, the Queue would grow perpetually, as you discovered. That's not good.
3. Activating the subscription after the first __send_command() does not fix the problem, but only postpones the effect. After using one LSS command as master, we would be in just the same situation, filling up with each unrelated LSS frame onwards.
4. A proper fix would be to store that a command has been sent and only act upon a response if there is an active command. That could be done by adding a locally scoped closure as subscriber in __send_command(), but it will be hard to guarantee that it will be unsubscribed again.
5. Maybe a context manager could help with a temporary subscription?
6. Any other LSS frames might be of interest, for example to get logged. For that case, a permanent subscription in the LssMaster is sensible, but then the callback would need to handle a message right away instead of simply piling them up.
7. Overall this code is not very well designed. A better pattern for managing the notification is needed. Hopefully something that's also compatible with using this method in an asyncio context?

I'm happy to postpone this issue until we have a structure for writing unified implementations that are able to work with either regular blocking or asyncio. Then we can refactor the design to something "proper".

I'll come back later to clarify what I mean by "unified implementations". I'm working on a general discussion about it. For this specific issue, the practical implications is that we don't fix this until after asyncio is in place.

I like the context manager idea for subscriptions, btw. That could be an elegant manner to handle other protocols as well.