I forgot to mention it, but of course member fields with no default values set forth in the class definition, but an actual value of NULL could be handled the same way (eg. omitted from output) in the "optimized" serialization mode, as member fields default to that value anyway after construction, so unserialize() would still produce the same object from the "full" and "optimized" strings.

This would create data corruption issues because one cannot see into the future. A code change will break compatibility with objects serialized before the change. Your proposal admits the choice to omit these defaults is done at the time of serialization, so there's no way to 'un-choose' having incorrect data in the future.

This is correct:

"This would create data corruption issues because one cannot see into the future. A code change will break compatibility with objects serialized before the change.;;;so there's no way to 'un-choose' having incorrect data in the future."

There is no way this request could be made to work safely.

It would not create any data corruption issues. 

First, because the compact version would be emitted only, if the developer choses explicitly to do so by specifying the second, optional parameter. Now, if the developer decides explicitly to do so, then he obviously knows what he's doing and knows what the implications of his actions are. 

Second, because if one changes the default value of a property, that already implies that any code that depended on that property having a specific value gets "broken" - regardless of any serialization of the object taking place or not. So obviously, if the object gets serialized and then deserialized, then that doesn't change that fact any more, or doesn't make it any worse. 

Third thing: saving all property values doesn't shield your code from breaking changes any more, than does omitting default values does. Why? Because even though you have all properties saved in a serialized object, you don't have the code manipulating, using and querying those properties (ie. the code in the class methods, and the code called by the latter, and so on) saved in it. So when you load back (deserialize) an object, it might very well have a different code base (methods, functions, etc) attached to it, than it had when it was saved. And if those changes have not been backward compatible or have not been tested thoroughly or are not capable of handling unserialized property data sets that were serialized with previous versions of the same object/class (with a different code set behind them), then they will break your program, too.

So, all in all: no, the proposed feature request does not introduce any kind of "data corruption issue" that could not be introduced by the features already present in the language. It would, however, enable some serious savings in data storage requirements and run-time speed advantages when handling large data sets with many properties left at their default values.