I would try one of (the second option is the preferred option)
1. Create a date island, not linked to the date model. Then use set analysis in your front end. When you make a selection, you can have each object show the data based on the date(s) you need.
This could over complicate your expressions and maintenance is high. And, not to forget, can result in poor performance for user experience.
2. Concatenate your fact tables and make sure you have matching keys (google Star-model vs. snowflake). For example, load orders once with OrderDate as primary key (AS %DateId) and then again with DeliveryDate as primary key (AS %DateId). Then link the master calendar to %DateId. When making a selection in your master calendar, data from both fact tables are shown, but both with different results.
Normally I would choose this option, because this allows for much simpler expressions and usually has better performance.
A master calendar is just a calendar (Year, Month etc) for a date. It should really just be called say a Date Calendar. And then Master Calendar could have been used to link to a Canonical date.
A canonical date is really needed (there is a non-script Date Island alternative but I wouldn't recommend this) when you have more than one date in one table if you only want one (master) Calendar.
If you have many dates in different tables. Canonical dates sometimes works. But care is needed as detailed in this Canonical Date thread (but also read the comments). If it doesn't work then concatenating tables and then using Canonical Dates if needed should work.
Or an alternative if only one date per table. Just concatenate the tables and use one common date field. Then a Canonical date is not needed.