That did work! I never would have thought logging out would be nessasary. When I change the setting there is no prompt about a need to log out, it just says user settings saved.

Many user options/attributes are checked and their corresponding behavior at login time. Updating the stored value for these options/attributes doesn't trigger a real-time re-assessment and re-setting of behavior based on the new value (for often complex technical reasons like some of those checks being part of login flows).

For a rough analogy, imagine you have a workflow that queries a database, which has a single column called "Setting", with a single row/value of "OriginalValue".

1. The Workflow starts and creates an empty token called "(SettingsQueryResultForSession)%."
2. Workflow queries the database with a SELECT for the value of "Setting", gets "OriginalValue" back, and sets it as the value of the (SettingsQueryResultForSession)% token. 
   1. [#1 and #2 represent the settings value being read during the login process]
3. Workflow runs an Update query that updates the database "Setting" value from "OriginalValue" to "NewValue".
   1. [You update the setting value]
4. At this point the value of the Workflow (SettingsQueryResultForSession)% token is still "OriginalValue". Even though Workflow just updated the source value in the database, that doesn't automatically also update (SettingsQueryResultForSession)%, so the value of that token will be "OriginalValue" for the remainder of the workflow instance.
   1. For $reasons, (SettingsQueryResultForSession)% can only be set once per Workflow instance, at the beginning.
5. The next time that workflow runs (you log in), the SELECT query will return "NewValue" and workflow will set that as the value of (SettingsQueryResultForSession)% for that instance.

Again, this is just a hopefully relatable conceptual illustration of why some user setting updates are stored immediately but don't take effect until your next login. Not here to get into any arguments over how things should/could/might work in the example =)

Note for other readers: Entry access rights are always evaluated server-side in real-time when a user attempts an action on an entry. The above is about user settings that are stored as Trustee Attributes.