Here's some further explanations about this issue and my software design concerns:

I have two aggregates: AggregateA and AggregateB.
Both of them have their respective TableA and TableB projections, linked by a many-to-many relationship through a TableATableB join table.

If an instance of AggregateA is created or updated and therefore its TableA projection too, the app must either create or delete TableATableB relationships with TableB, and vice-versa.

As of now, this workflow is actually done by the event handler of EventA and the event handler of EventB:

• When the event handler receives an EventA, it queries the database to retrieve all TableB records using TableA and performs a calculation on which relationships should be updated. But because the event handler doesn't have any guarantee that TableA has effectively been persisted, it randomly fails.

In order for TableATableB relationships creation/removal to not depend on an projector and therefore on db inserts, EventA could carry a list of related TableB, and its projector would just have to insert both TableA and related TableAsTableBs projections in a single transaction, and vice-versa. This also ensures that if any operation fails, the whole transaction will be rolled back.

But if I do that, AggregateB would have no idea about the relationships stored in the state of AggregateA, and conversely, if AggregateB has been commanded to perform the same action from its side, AggregateA will have no idea about the relationships stored in the state of AggregateB. This will lead to have up-to-date relationships in the persistence layer but with both aggregate states being out of sync. If one day my requirements are to retrieve the exact value of relationships between AggregateA and AggregateB, I'll be in trouble.

How would one deal with it?

This also raises the question of which state should be the source of truth in a relationship between two aggregates, and which events are responsible for updating relationships projections?

"It Depends",

Yes, avoid dependencies between Projectors (Event Handler) and Processors (Event Handler).
An Event Handler should be as sufficient as possible by itself, since the Event Handler is a linearization factor, otherwise it may be difficult to reason and implement the system.

That means creating a Processor own its Projections as well. The anti-pattern (especially as the system grows) is to use somebody else Projection.

Once again, "It Depends".