My first instinct is to go the cookie at the session level route. When the session is destroyed their current company is cleared. Since this functionality is switching and not really related to persistency, I would avoid storing it on the user model. However, that said, it may make sense to have a preferences model (or attribute on the user model) for "default company" which would allow the user to select what their preferred company is.
I do have this in my backlog and plan on attacking this one after the current series. You are right though, there are very few resources around this and it can be a rather large task.
☒ You really don't need the instance methods in that example, It can be done at the class level. If I were to go back and redo this episode, I would leave any class level qualifying methods out of instance level methods.
One thought, let's say you have a very complicated application (think ERP) and you have an onboarding wizard. This can take some companies a long time to complete and things need to happen in a certain order. As some stages are completed, a lot of background API calls are made and data is synchronized. Using State Machines may be a viable solution in these kinds of scenarios.
