Dear Svenja,
As you already said, there are no n:m Associations in BOPF. Every association is directional with source cardinality one. Nevertheless, it is possible to picture e. g. the relation between products and orders – with two different associations, but with cardinality unbound.
I was thinking about this a little longer now and believe, that this is actually true for all n:m relations: I’d even say that there are no real n:m associations, but only n:m relationships. For me (and technically for BOPF), an association is always owned by an entity. This is also expressed by the fact that association changes are propagated via the service manager for one entity. However, at runtime, a link-table which is the runtime-representation of an association can have multiple source instances pointing to multiple target instances and vice versa. This is due to the fact that the association can be resolved for multiple source instances, each of the being of unbound cardinality – but not restricted to point to different target entities.
Thus, I do not see any reason why not to model two associations.This would mean to have one service with two entities with two (directional) associations.
Coming back to your sample, the association between products and orders is actually at item-level: One order item can relate to one product. One product can occur In multiple order items.
The relation between Order and Product is actually a “shortcut” for /Orders/$expand=items/$expand=products (if one can note this in OData like that, I’m not there yet 
). The relation from Products to Orders is also a shortcut for /Products/$expand=orderItems/$expand=toParent - at least in my mind. All of these associations could be modeled (based on (reverse-) foreign-key-mappings). The shortcuts could be realized with implemented associations which relate orders and products directly (internally following the items-association). However, I’d discourage from doing so as implemented associations cannot be pushed down to the database (as joins).
Is there any reason why not to implement your requirement like this?
Cheers,
Oliver