On the whole @naturzukunft you may be interested in @cwebber 's work on Spritely which perhaps fits better with some of the expectations you’ve laid out that I’ve disappointed.
Yeah this is why some softwares do not support sending the Update activity for certain kinds of content. But you’re right, there is a slow cache-consistency problem. Imagine if we federated via ActivityPub over sneakernet… I go sailing and type up a bunch of notes, including Updates to things you already have cached, and I generate activities, but I don’t have internet access. A ship passes by, and I can federate with them. They have the Update, no one else does. That ship can carry it further to share with the rest of the world, as could mine. ActivityPub accommodates this slow eventual consistency, and can survive divisions of the network (and heal when they’re re-connected).
Apps may demand real-time “global state”, and this is the key tragedy of Blockchain-like decentralized thinking. Trying to have decentralization but also demand global consistency. That is not needed in federation: decentralization, with a window into “the world” and yet acknowledgement there’s more out there that we don’t know. Perhaps a little too philosophical.
A lot of people wish to remain “compatible with the Mastodon-flavor of ActivityPub”, but it is certainly not required.
FYI ForgeFed had a similar problem and solved it using Offer flow:
The offer flow begins with an Offer activity, in which object is the object being offered for publishing, and target indicates under which list or collection the sender would like the object to be published, if the target actor accepts the offer and publishes it.
Thus, across federating instances, https://example.com/max can Offer something to https://anotherone.net/thomas, then Thomas can Accept it and then do the usual ActivityPub behavior.