I can think of two options for this scenario
MUD will work. You can keep the RPD in a shared path. Then create projects based on users. Say for example create a project With Subject area A and another with Subject area B. Users can access both simulataneously and work on it. Only thing is check in is possible for one user at a time. But still it will work great.
2) Trim and Merge.
Provide the RPD to different users . (But you should make sure that they are not working on same subject areas).
Once they complete development Trim their RPD with the required Subject area.
1)Find the Business model and Subject areas for a particular database from Repository(it is very easy, right click and view related objects.
2)Then find the initialization blocks for the connection.
3)Variables for the initialization block.
3)Application roles related to your Subject area.
Delete all other objects in RPD.
Then keep a master RPD and remove the objects which are available in the trimmed RPD.
I can suggest you scenario only one best option MUD. Please enable and start the development.
Why I am suggestion this because you’re having one common rpd across all developers. If you go for 2 way or three way merge process it is very difficult to identify the impact analysis.
If go for mud implementation, while check in process itself you came to know that where it is going to over hiding and errors also will display .I can suggest this option.
Satya ranki reddy