Now that I have your attention...
We are seriously considering deprecating the SoapFormatter in .NET Framework 2.0. It is the nexus of a whole host of serialization issues and implies a promise of interop that it does not and will not live up to. It also does not support generics. Additionally, those of you interested in the new Version Tolerant Serialization features in .NF 2.0 will note that it is not supported on the SoapFormatter. This means that types using VTS to introduce new fields would break when serializing between versions over the SoapFormatter. This is also true for framework types. So if you are using a framework type that adds fields in .NF 2.0 and you do not upgrade both apps using the SoapFormatter to .NF 2.0 then you could see serailization errors occuring simply by upgrading to .NF 2.0 on one side. Before you ask, no I don't have a list of framework types that might break in this scenario but the question is whether requiring switching to the BinaryFormatter is unacceptable.
The obvious solution to this is to switch to the BinaryFormatter. It supports VTS, the serialization of generics and is one of the Cross-AppDomain formatters, where our guidance recommends the usage of .NET Remoting for new applications.
This is our stance as of Beta1 for .NET Framework 2.0.
So the questions is: Who has to have the SoapFormatter in .NF 2.0 and why?