I'm not particularly familiar with the specifics of Unity so I'll leave question #1 for now -- I have an idea of how to fix it, but an explanation tailored to Unity would probably be better if someone can provide one -- I'll respond later if noone else chimes in.

For question #2, basically your idea of a "sweet spot" is correct: you can read about how Pac Man did it in The Pac-Man Dossier. Essentially you want to allow the player to turn as long as they input within a certain range either before or after the exact centre of the turn -- give some leeway and then ensure you move the character back onto the correct path.

Well, if you read up on Pac-Man and similar games, you will figure out that the movement is not really pixel based, rather grid based. You are always aligned to the grid as far as the game, collisions, etc... is concerned. The reason it looks pixel based is because it animates the movement between grid points, but the grid alignment issue will perfectly solve your problems.

The way I would do it in Unity would be to forgo the physics system altogether, at least for gameplay. Instead, I would have a gameObject with a script on it that defines the level. This could be created in an array, which could either pre-define the level by hand(or some editor), or on the Start function do some raycasts and figure out exactly what objects are where in the grid manually. Then I would determine where in the array the character is starting. When you move, it counts the character already in the next spot, but you can use a CoRoutine(or something like an iTween which ends up the same as a coroutine) to make it move from one grid spot to another. Then your collision detection would be as simple as checking an array index for an empty value.

As far as collectibles etc... you could still have those by a physical entity in the world if you wanted, but if they are enemies or need movement, they need to use that same array.

As far as input, if I'm not mistaken, Pac-Man just stores whatever the last direction the player inputs, and when it is on a grid point it determines if you can change to that direction, and if so, does it. This is how you can see people so easily control Pac-Man because they don't have to be perfect on the input if the game stores the last direction like that.

I have a game that works in a similar way to pacman (ie is a tight maze). I have 2 issues.

1: I have a player object which is around 50 pixels square and I have added a boxcollider2d to it that is 60 pixels square. I am trying to move this player down the corridor which is 60 pixels wide but if I press against the wall it seems to get partially stuck and moves as if it is in treacle until it is clear of that particular wall tile. It also seems to get completely blocked occasionally by wall tiles. If I make the boxcollider2d 58 pixels square then my player moves fine even after being pressed up against a wall tile. However this also means there is some sideways movement in the corridor by 2 pixels as the object is no longer exactly the same width as the path.

2. If I am moving say to the right and there is a path leading down, I have to be pixel perfect in my alignment in order to change direction. Pacman never has this issue. Do I need to have a sweet zone where it automatically aligns my character with the path or is there a better way?

Here are a few random suggestions in no particular order:

1.- Turn friction and restitution to zero.

2.- Turn your walls into edges and link them with "vertex0" and "vertex3" (Box2d manual: chapter about "edge shapes" and "chain shapes").

3.- Turn your character collision into a circle, not a square.

4.- Turn your character collision into four, small, revolute-joint circles (north, east, west, south), so he "rolls" along the hallways.

But to be honest... It seems to me that using box2d is giving you more headaches than solutions.

Unless your game really needs them, I suggest you forget about realistic physical collision and just implement your own solution for this game... the way pacman did it.

Well, isKinematic doesn't exactly just turn physics off. It just makes it so that object "dominates" in a way, allowing you to move it directly and to not get pushed around by physics objects. And yes, it would make your collision event not get called. There is a chart in the Unity documentation that shows what all settings get things colliding, specifically things with/without rigidbody, triggers, isKinematic, and what combinations of settings trigger what types of collisions(and trigger events).

I'd still suggest simply not using the physics for this. You are wanting precise movement, grid-based, and the physics system generally isn't good at that. You don't need it, and you are wasting time both design time and making the game take more CPU cycles than it needs. The physics systems aren't meant for all games. The only thing you need it for here could maybe be an easy way to set up trigger events to detect pac-man picking up pills, and eatings ghosts. Besides that, it is truly not worth messing with for this game. Now, if you were actually doing something that needs physics, maybe. But that would mean not having grid-based movement, rather something a bit more free.