I have been using Mastodon for a couple of years now and frequently can't access media which is more than a couple days old from other servers, and I see only a subset of the replies, toots and stars...
The "subset of the replies" issue likewise isn't inherent, but is somewhat more problematic as it requires everyone to behave in ways that makes it work, e.g. push replies back to the origin server, and regularly poll the origin for additional replies etc., and Mastodon itself is not great at his.
To the extent AcitivityPub itself is affecting any of it, it's only in the sense that ActivityPub imposes very few constraints on implementations, and that leaves a lot of room for specific applications to behave in counter-productive ways..
Mastodon has the similar problem but worse with content discovery; a user is not "seen" remotely by anyone until one remote person finds them and subscribes to their content explicitly. On every single remote instance, which of course is undesirable but that's how ActivityPub is designed.
I don't believe in ForgeFed terms this matters as much as being able to search across the federated network for repos, etc. which I think is a key feature. Sure issues and user accounts and whatnot, but an AP-linked FF-wide search would be insane on how useful it could be for users (and how to implement a "distributed search index" seems like a tough nut to crack).
For Lemmy the hub and spoke model is essentially intentional - groups "belong" to a specific instance. But there's nothing in ActivityPub that'd prevent a USENET style model of groups either. There's nothing in ActivityPub that prevetns an application where a collection is effectively open to writing by all, and that would then relay messages to a sufficient set of "downstream" instances.
It'd be interesting to have that as an alternative to the Lemmy approach - I think the two could live quite well side by side.
This reminds me of the design model of SearX/SearXNG - instead of a distributed forge index, it would distribute the search endpoints of forge instances to facilitate the next steps you outline. It almost feels like a central coordinator or maybe a CDN-like network set of search proxies would be needed to do the actual combining and filtering of results. Maybe it could fit in the Codeberg operational umbrella in some future plan.
In practice Nostr does this step on the client side - one subscribes to relays, then when querying for new content it asks all relays, gets all the duplicate metadata and filters on the client. Huge network use and battery drain on your handheld device, Nostr bouncers have emerged for this exact same reason, a popular software is "Bostr", easy to find examples run by random volunteers but it requires money (disk/cpu/ram): https://bostr.azzamo.net/
You can also certainly broadly cache the "top" of the hit lists for very common searches, so you don't need to fan out unless you're doing less common searches or going beyond the first "page" of results.
AP fundamentally rests on exchanging activities, that model operations on objects in collections.
Everything under their "basic concepts" section can map cleanly to an application that speaks AP.
AP has actors. Methods maps to Activities. Making networking transparent is down to wrapping things in a local framework that chooses when to use networking. Their concept of "vats" similarly is down to a lcal framework that calls method if local and posts AP activities otherwise.
AP provides a format for storing both the activities and other objects to disk, but you can choose to use your own, and that includes state that might reference other actors.
I'm working on an app server, in fact (not open source) that is based around those concepts and provides all of the things they're describing, but currently with AP as the main external protocol (that is likely to change - e.g. we're likely to use NATS for communication internally in clusters of these app servers).