As both a GDAL and MapServer developer, I would consider the C# bindings of both projects "mature". Tamas Szekerest does a great job working to keep feature parity between the Python and C# bindings of GDAL/OGR. While the basics of both the C# and Python bindings are essentially the same in GDAL/OGR, niceties around the edges can and often are quite different (raster data handling, for example).
The MapScript bindings for both Python and C# are generated from the same SWIG interfaces, and Tamas does a great job on these as well. The SWIG bindings for MapScript in general are quite stable in the sense that they haven't changed much in the last number of years. I am not an advocate of using MapScript, however, as a number of things have changed in the last couple of years that make the enforced rigidity of MapScript no longer necessary. If you are rewriting your application, this would be a good time to take advantage of these new features.
It is now possible to use MapScript to load chunks of text-based MapFile fragments in to various MapScript objects (including an entire mapObj -- see *loadFromString methods). This means that you can utilize your own (or your language's) templating tools to generate MapFile and send it off to MapServer without laboriously instantiating tons of MapServer fooObj's, worrying about their object lifetimes, and deciphering their various relationships. Another fact that makes this approach attractive is MapServer is first and foremost a CGI application, and MapFile is the real specification of its usage -- not MapScript. Features and behaviors MapScript almost always lags what happens in MapServer's MapFile mostly because the later has many times more users and developers than the former.
Another mark for MapFile is that a modicum of backward compatibility is preserved in its parsing -- hardly any is done for MapScript. Take this opportunity to free yourself from maintaining a MapScript application and simplifying its design with your language's templating facilities and some simple MapFile fragments.
