Did the green one go straight through the brick wall or did it actually find the right way?
In any case, this is not supported right now and there is no simple code change that will fully support rotation-aware pawns. If a pawn only needs to rotate once before navigation begins to reach its goal then one can easily test various pawn rotations iteratively and test pathfinding for each rotation. But in a more complex scenario a pawn may need to rotate several times in the course of navigation to successfully complete its journey. Maybe it rolls 90 degrees first to squeeze through an opening and then it rolls back to original state to squeeze through another, etc. So if your usecase is that complex you’ll need to test suitable pawn rotations for every voxel and also memorize the rotation used at each voxel as part of the results. I expect this will have very poor performance without carefully tuning and optimizing the algorithm end-to-end specially for this usecase.
If your bot has retractable wings and rolling is not a gameplay requirement then you can apply a workaround:
A creature with retractable wings (like a bird) doesn’t need collision bodies on the wings because a bird will simply retract its wings to squeeze through tight corners. That way you end up with just one collision voxel (on the core body) which is better for performance too. Even if you really need collision on the wings, you can always set their collision profile to something that the plugin isn’t configured to pick up (eg: BlockAllExceptNav). In this scenario you’ll still need to retract the wings to allow the pawn to squeeze through though.
Another workaround along these lines would be to exclude the wing’s collision bodies for navigation queries (like I explained above) and use supplementary triggers/line-traces that tell your bot when it needs to roll to successfully squeeze through a gap.