If $sc_Resources isn't being set, it must be because the value in the CalendarInterface::ValueList field doesn't exactly match the name of a value list in the file. Use the Script Debugger and the Data Viewer to monitor the contents of CalendarInterface::ValueList on startup. Maybe that field is empty when the failure occurs?"
That's not what I am seeing. Calendar interface::ValueList has an appropriate, matching value both when the menus work and when they fail (it can be the same value). The failure is evident upon the first execution of Load Resources ($Sc_Resources is empty and the default resource list loads into $$Sc_ResourceList instead), which as you know is very early in the startup.
Stranger still, I can launch the Calendar 10 times (or whatever) and the partitioning menu works, a fact that is evident upon watching the first call to Load Resources. Then on the next 4 launches (or whatever) it doesn't. Switching from Filemaker Pro 11 to Filemaker Pro Advanced 11 (or the reverse) seems to make a string of failures more likely, as does logging out of my Mac user, then back in. That suggests that successes depend upon some sort of application caching which is lost with these switches. Given how little happens at startup before Load Resources is called (and the problem is apparent the first time it is called), and given that I otherwise change NOTHING between launches, it's all very strange and frustrating.
One more clue, but I'm not sure to what. For many users I have the Calendar launch directly to the Schedule tab of the Calendar layout (that's where they're going to live, as they are scheduling appointments for several mental health clinicians.) (I've removed your original Calendar Home layout). Other users are directed to the Week tab (the calendar is filtered to show just their events. They'll live there, scheduling their own clients.) The decision to go one direction or the other is the last action performed in Upon Opening, and therefore occurs after the first call to Load Resources. IOW, for some users the calendar runs Perform Script ["Go to Calendar Tab (Tab Name)";Parameter: Calendar Resource Scheduling - Vertical"], while for others it runs Perform Script ["Go to Week"]
For those users destined for the Schedule tab, and ONLY on those occasions the resource partitioning menu fails to operate, there is also a very long delay (complete with spinning OS X beachball) before the calendar displays the schedule and becomes operative - about 10 or more additional seconds. When that happens, on inspection I find that the Insert into Calendar { Column } script hangs for some time on the Set Variable step just below the comment, "Get Column: Day of Week, Resource (Vertical) or Time (Horizontal). There the variable $$sc_Column is set with a complex calc that appears to hang (<- just guessing).
At any rate, it appears that whatever is causing the menus to fail also causes a long delay in taking the first trip to the Schedule tab. But only sometimes!!
BTW, I'm using data separation for performance. The calendar interface resides on user laptops, while the Events table and an extensive contact tables (more than 5000 entries) reside in a file that lives on Filemaker Pro Server based hosting service (Datatrium, for now).
I really like this mod, and will probably have my users relaunch to get it to work, but that seems pretty lame!