Yes, sure, with these semantics the names are right.

Cool. I actually think we have very similar understnading of semantics and naming in this case.

Ouf interest, what are the requirements for having the mechanism in that way? It seems more complex (all the reference counting, clients must not "forget" to release a service etc.) than a mechanism which just initializes a service upon first usage and closes it when e.g. the search factory is closed. Are there services which are started/stopped several times in the lifetime of one search factory? I'm just trying to understand the motivation for the current implementation a bit better

I think I need to explain this bit more. I already mentioned once that this whole referencing counting business was open for discussion. It is not something I introduced now, but I kept it from the original code. Do we need it? I don't know. The use cases we have and the ones I have in mind don't need it. Is it worth removing? I don't know. I am not rewriting this code for the fun of it. Even though this is a quite big change, I tried to keep it to a minimum to get a working service mechanism (at least for my undemanding on what such a thing needs to do). As discussed the existing approach did not work once we had actual modules (e.g. serialisation). The request/release counting on the other hand worked, so I did just keep it. I am open to remove it, but I think that should be another issue.