Don't forget that the way the engine calculates non-parallel collision cylinder movement along walls can cause snags due to overhead BSP/object additions/seams. When the engine goes to update the object's location (from what I can tell) it first performs a trace (with an extent equivalent to the pawn's collision cylinder size, a world coordinate aligned prism) in the direction of the expected movement. If a wall is encountered, at least one additional trace is performed in the same direction only that the Z value of the start and end locations are offset by the MAXSTEPHEIGHT defined in pawn (or actor?) which has typically been 35UU (note that when physics is phys_flying this offset appears to possibly be tested twice, once by adding the offset, and another by subtracting the offset), this is how walking up stairs is handled (there must be another trace performed to find the final height to adjust up as well). If an object is hit by the trace then the resultant movement is adjusted to move along parallel to the surface (surface normal "crossproducted" with Z axis, then maybe dotted with the movement vector), or sometimes treated as a "hard" hit and resultant movement is stopped/zeroed altogether.
Since the trace extent prism is always world aligned, I think it would almost always come in contact with bsp walls that are angled because of its "corners". I remember reading somewhere over on the UDN that collision with static mesh actors is handled slightly differently (the radius of the collision cylinder component is taken into account more) so you may want to try placing an invisible flat static mesh "wall" along the surface a few UUs away from the BSP surface and see how it works if the blocking volume does not do the trick.
