TLDR; Duplicate modes don't appear to be an intended way to set up different days. Bad things happened when I created duplicate modes. There needs to be an update to prevent a user from creating modes with duplicate names.
I was thinking "modes with the same name must be the same thing". Looks like that's not the case. I had a mode named "Test". I created a second mode also named "Test" with different day/time triggers. I then tried to set up a rule in Rule Machine to using Test mode as the trigger. In Rule Machine, there are two entries with the same name:
I created two rules, one triggered by the first "test" mode listed, and one by the second. The rule just writes a log entry to say it was triggered.
When I went to the integrated mode manager and manually activated either "Test" mode, only the rule where I selected the second one fired. No matter which copy of "Test" I tried to activate, the rule I created where I had selected the first "Test" on the list would not trigger.
I switched the first rule to use the second trigger, and then both rules fired. So only the second instance of "Test" on the drop-down list was working. A rule based on the first instance of "Test" in that drop down would never fire.
To clarify, no matter which "Test" mode I tried to activate, the FIRST one that I created was the one that showed active. But that seemed to correspond to the SECOND one in the drop down list in Rule Machine.
When I click the button I circled in green, the active flag gets set on the other mode.
I couldn't find any way to activate the second Test mode. To make sure the bug isn't only with manual activation, I switched the second Test mode to activate at 12:02 PM. When that time arrived, the OTHER test mode activated. This screen shot was taken at 12:03.
In the logs, there are debug entries for app #1417 (Test mode setter) and app #1439 (Test mode setter).
I'm a bit surprised by this. I expected that the mode names were just a label and the real mode was an integer. The logs kind of confirm this by showing:
processing action for [mode:7, actionType:setModeUnlessAway, deviceIds:, description:Set mode to Test, index:0, type:then]
for one of the modes and
processing action for [mode:5, actionType:setModeUnlessAway, deviceIds:, description:Set mode to Test, index:0, type:then]
for the other one. But if the name were truly just a label, I would expect that I would have been able to get the 'active' flag to appear on either Test mode, and I would have expected I could trigger a rule based on either Test mode. Instead, it seems that despite one being shown as mode 5 and one as mode 7, they are interfering with each other due to the name/label being the same.