Chalk up four hours lost to a bug in .NET.

The binary and soap formatters have a bug where they don't use the value
returned from ISerializationSurrogate.SetObjectData, which is
disappointing because it seems like a primary reason why someone would
want to use a serialization surrogate.

Background:
A serialization surrogate lets you control the serialization of OTHER
types.  If you have a type that you need to manually handle the
serialization, but can't change the code for that type, you would use a
surrogate.  For example, you may be using a component that includes type
A.  You have an object graph you need to serialize that contains type A,
but the graph won't serialize because A doesn't have the Serializable
attribute.  You can create a surrogate for type A, tell the
BinaryFormatter about it, then have the surrogate handle the
serialization.  

Theoretically, and by the definition of the interface, you _should_ be
able to return a completely different type.  This is my situation.  I
have a base class that isn't abstract.  There are a number of classes
that extend this base class, but I'm also using the base class by
itself.  I've run into a situation where I need to "cast up" one of the
base class instances to a derived type when deserializing, to maintain
backwards compatibility.  I _should_ be able to implement a surrogate
and, in the SetObjectData method, return whatever type of object I see
fit.  Unfortunately I can't.

Back to the drawing board.....

-jk