Yes, this is a good point. Though the issue you raise is a more universal one. In a future fediverse there’ll be more and more different application types that are interoperating in all kinds of ways. The question of ‘which client supports what?’ becomes much more prominent then. Potentially very confusing for fedizens, unless specifically addressed.

On the one hand this can be done via standardization or strong consensus on what ActivityPub extensions to use, and Capability Negotiation, and on the other hand - on the client side - a move to more “universal clients” (supporting the Client-to-Server part of the AP spec, and NOT the Mastodon API which can never keep up with all this) is a way forward.

Offering an intuitive UX for that will be challenging. You might say that with all its different apps, the fediverse represents a kind of ‘cloud-based-appstore’, but that doesn’t cut it. I think at this time the fedi will become more service-oriented, while the client devices may become more task-oriented. See also: From silo-first to task-oriented app design.