Glad to hear it was easy to follow.
In terms of downsides of multiple PlayerControllers, I never actually ended up attempting to use multiple as when I initially looked it up in 2014 it seemed convoluted and not very runtime-friendly.
In terms of changing PlayerController - there is a “SwapPlayerControllers” function in the GameMode class. You would likely want or need to create a game mode deriving from the base AGameMode class to make use of this; though I have heard people having issues with swapping PlayerController over the years and as I have not attempted it myself there may be a better approach.
For binds - I’m not sure sorry.
On top of the “convoluted and not very runtime-friendly” issue that led me to the single-PC solution there is also my preference as a programmer to encapsulate all input handling into one input handling system. That is why I chose to stick with one PlayerController without handling input inside of pawns/characters.
I have implemented pawn/character input handling in the past but I found it gets messier the more complex input becomes and most of your input handling ends up being done in the PlayerController anyway.
If you would like to separate input for each input mode but retain a single PlayerController for simplicity, you can always create a custom sub-class for each input mode to have specific input handling contained within them to trim down the PlayerController implementation (this could be done through deriving from UObject so that it is still a UE4 class).
That may make it feel tidier and easier to work with, where you would just create and store the sub-classes in the PlayerController and then could bind the input to the specific sub-class (you would still need some sort of state so the sub-class knows it can act on input in case the same input keys/buttons are bound to multiple input modes).
I can give an example of how to setup that latter one too if you like but I really do need to get to bed first 