####
#### <-- wall
+---+####
|mob|x
|-->|x
+---+
I'd use obounds() to get the space occupied by the xs in that diagram. It's a box that's in front of the mob and slightly narrower than them. If they bump a wall but that box is open, move them away from the wall. Based on what your environments look like there are different ways you might size and position the bounding box.
The Pixel Movement library has some helper procs that'd almost cover this. The front(p) proc returns a list of atoms in the bounding box that covers the p pixels in front of the mob, but doesn't take a width (it only uses the mob's width). It's not a complex proc and wouldn't be hard to add a second argument for the width.
There are also alternatives that don't involve sliding the mob automatically when they hit an obstacle like that (since most games don't actually do that). With the Pixel Movement library you will slide along the wall if you're pressing both the right and down arrows. There's no automatic sliding of the player and you still get around the obstacle easily. If you had situations like this:
#####
#####
+---+ #####
|mob|
|-->|
+---+
#####
#####
#####
Where the mob is just the right size to fit through the opening, there are two preferable ways to handle it:
1. Make the mob naturally line up with tile boundaries as they move. For example, if you're moving to the right, make minor adjustments to line them up vertically with tile boundaries. Provided they can move themselves to within a few pixels of being lined up, these automatic adjustments will line them up the rest of the way.
2. Don't make passages that are exactly the player's size. Even if the player's icon looks like it fills the full 32x32 box, make their size 30x30 or 28x28. You won't notice a huge different and they'll be able to fit through narrow passages more easily.
One thing you could make a good case for would be the inclusion of helper procs that would make this kind of thing easier to calculate. You can get a dir from one bounding box to another, but it doesn't tell you if one direction has either a complete or partial overlap. Nor is there a get_dir() that tells you the direction you'd need to align the centers of both boxes. You can get a distance from one box to another, but not the "oblique" distance (that is, you may be 20 pixels away in the x direction but -3 in y). Those procs would obviously help.