No. But the limitation of 2 Master-Details has no effect on the number of Many to Many relationships an object to have.
1) You can use lookups to accomplish the exact same thing as a Master-Detail if the only requirement is to have a Many to Many relationship.
2) The limitation of 2 Master-Details per object has no effect on the number of Many to Many relationships that use Master-Detail. In a Many to Many, the Master-Detail relationships goes on the child junction object not the parent object itself. That means all you need to do is create more junction objects (which is what makes the object many to many), with each having the maximum of two Master-Detail relationship fields.
Account <- -> Contact: Junction of AccountContactRole to create a Many to Many relationship
Account <- -> Special_Asset__c: Junction object of AccountAssetType__c to create Many to Many relationship
Account <- -> Case: Junction of AccountCaseLink__c to create a 3rd Many to many relationship.
You now have 3 junctions that all use Master-Detail to create Many to Many relationships. (Keep in mind that these are Theoretical objects I am using here and so likely make no sense in your org past my example.)
I disagree with the "common knowledge" on this issue. I have run into use-cases where using a Lookup relationship instead is appropriate. The junction object is a more flexible concept than people give it credit for. I agree that the following are preferable:
- Junction should only relate to two objects
- Junction should never be orphan
However, these requirements are not terribly difficult to satisfy without the use of Master-Detail relationships. For example a Validation Rule can count all the lookups and make sure you have exactly two.
A Concrete Example
Let's say you want to mimic polymorphism in your junction. Consider, for example, if I have one object that I want to relate to five others via many-to-many relationship. Do I create five separate true junctions or one junction-like object? There are valid arguments for each side, but to flat out reject the mock polymorphism because it uses Lookup instead of Master-Detail may not be an option in all orgs (sometimes you are limited to ten custom objects).
Best Answer
I see two reasons if we use look-up instead of master-detail type relationship:
When you delete parent records, its child records will not be deleted. In case you delete both parent records, that linker record will be an orphan record and will eat your expensive storage. You will require an extra mechanism/components to trace those type of records.
Security and Sharing will not be applied from parent to child. User may have access to child object record but not of the parent record. This causes inconsistent behavior.
There can be more reasons depending on use cases.