If the client wants to request via slapo-allowed which attributes are readable/writeable before adding another object class then object classes not yet part of the entry could be used if the client adds the object class name prefixed with @. This is an extension to the semantics but should not cause any problem with existing clients.

with the current implementation of slapo-allowed, the client does not do anything specific but requesting those special operational attributes.

It is not clear to me how the semantics you propose should be activated. If you mean that having some "@" + <objectClass> in the requested attrs should populate the allowedAttributes and allowedAttributesEffective attributes, I think it would be a significant distortion of the meaning of the requested attributes.

I'd rather favor defining a specific control request, that sort of "mimics" adding some attributes, including objectClass values, to an existing entry, so that allowedAttributes and allowedAttributesEffective are populated accordingly.

p.