By “physical” I guess I mean functionality related to how the pawn appears in the world, like movement, animation, anything directly affecting the pawn’s skeletal mesh, etc. So Add Movement Input, rotations, jumping/crouching, etc. go in my pawn/character classes. My reasoning is that I want to encapsulate these functions in separate classes if I’m expecting them to vary among pawns. E.g., my default biped has a walking animation BP, can move, rotate, etc. but can’t fly. My “free camera” can fly and isn’t affected by gravity but doesn’t need an animation BP. If I had something like a stationary turret, it would have its own anim BP and could rotate but wouldn’t fly or even move (so it wouldn’t need any Add Movement Input nodes). In Menu mode, movement of all pawns is disabled and “MoveForward” changes the focus to the next button instead.
All of these classes react differently to the same input, so I want the input to be handled in a separate class in order to decouple it from “responses” to input. In my case, I have generic “InputPressed” and “InputReleased” event dispatchers on my PlayerController class (with an enum parameter specifying which particular InputAction was received), and I bind Character/Pawn/UI events to it at runtime, but there are probably other ways to get the necessary classes to “listen” to the PlayerController. I could also put variables like the player name and XP or money on the PlayerController and have that persist between pawn changes, although those might be better to put on something like a custom PlayerState (in multiplayer) or GameInstance (if they need to persist between level changes).
Of course, a lot of this would be unnecessary if I only had a single Character for the player to possess, so your needs might be different.