Why does IParamValueQueue derive from FUnknown

It seems the correct way for the host to support automation is to create one of these objects for every parameter ID that is changing within the buffer (with at least one point)? This feels overkill so I’m wondering (hoping) if I have missed something here.

I’m struggling to understand why these are implemented polymorphically and why a plugin would query these individual change events as an interface. They are returned by the IParameterChanges with type information, so why would they ever need to be queried? Furthermore, why would these ever be retained by the plugin? This seems odd given there could potentially be large amounts of them created per buffer, and enforces the host to implement them on the heap and manage their lifetime according to the retain/release semantics. I’m hoping I have misunderstood and there is a simpler and more efficient solution? (Or perhaps they have some other usage or purpose which I am not understanding?)

I don’t know why it was chosen to use FUnknown as base for them, but a plug-in should never call addRef, release or queryInterface of these interfaces. As a host you can safely return kNotImplemented for queryInterface and a static high integer from addRef and release for these objects.

Ok thats good to know
Are there any other classes which can be treated similarly, with the same assumptions?