The new ACRX_DXF_DEFINE_MEMBERS arguments determine which version to use when an object is to file itself out. When a drawing is saved, you can determine which DWG version to save to by calling the dwgVersion() method of the filer. It is not necessary that the object file itself out as the same version as the filer. Previous releases of AutoCAD have done exactly that, which has led to problems that are best described by the following example.
In Release 14, a new data member (mTreatElementsAsHard) was added to AcDbDictionary. In AutoCAD 2000, a new class called AcDbDictionaryWithDefault was derived from AcDbDictionary. When using acdbSaveAsR13() in AutoCAD 2000, the mTreatElementsAsHard member was not written out since Release 13 doesn't know about the member. If the drawing saved by acdbSavedAsR13() is opened by Release 14, the instance of AcDbDictionaryWithDefault is loaded as a proxy, since Release 14 doesn't include this class. When an AcDbObject becomes a proxy, all the data below the AcDbObject level is kept intact by AutoCAD as “proxy data” and is not changed. When the drawing is saved by Release 14, the data is dumped back to the DWG file as it was read in. The result is a Release 14 DWG file that has an instance of AcDbDictionaryWithDefault that is missing the mTreatElementsAsHard data. When reading in this drawing with AutoCAD 2000 or later, AutoCAD (specifically, AcDbDictionary::dwgInFields()) looks for that data member because the filer indicates that the drawing is a Release 14 version and the mTreatElementsAsHard data member should be present in an R14 drawing dictionary object. However, the data is not present, the sequence is lost, and the drawing is corrupt.
This is not specific to AcDbDictionaryWithDefault. New classes introduced by ObjectARX or third parties can suffer from this problem, especially if one of their superclasses has changed data.