Well, I may be getting ahead of myself here. I'm not really focusing on Kimballs methodology here because regardless if Kimball posted an article on not, I'm more focused on the problem at hand: how can you implement multiple calendars? This is extremely easy to do and it's pretty obviously the technical details you're searching for are missing.

If you want to implement multiple calendars to your fact then you're going to need to have those attributes to filter to the calendar. Otherwise, that calendar key is going to cause a many-to-many relationship across the various calendars, which will require you to implement a junction table that effectively do the same thing. This is assuming the Kimball article is referencing multiple calendars. If it's not, then there is a 1:1 relationship because only one unique calendar key exist for every one unique date key right? The moment you have multiple calendar keys, then that's going to duplicate the date key, which is the only key are you joining on from the fact (this is a problem).

This leaves us with the solution outside of that article, which is you're going to have to find some way to associate your fact to your calendar. You can do this in the fact itself by again, adding a key to filter the calendar dimension or you can add a junction table that will associate an existing key in the fact to the calendar table such as maybe CustomerKey, OrderDateKey and CalendarKey together to formulate that 1:1 relationship.

Course, the one thing we all may not be considering is maybe that date key is not a numeric value for the actual date that's reused across business units, but actually a sequential value where the dates in the DimDate key are duplicated across business units. This means every business unit in the fact has it's own set of unique date keys, which will effectively filter the DimCalendar table. But, that's no different than adding the business key to the dimension and duplicating the same values per unit.