Using interfaces in DataContracts for WCF service versioning.

We are implementing WCF Service versioning after having problems  with enums in response  (  Do not expose enum in WCF response )
I found that we need rigorously follow the recommendations “Versioning When Schema Validation Is Not Required” from msdn article:
Best Practices: Data Contract Versioning

Initially I’ve ignored the recommendation “Do not attempt to version data contracts by type inheritance” and failed to generate backward compatible XML.

Reading the documentation I’ve noticed in Service Versioning article
an example
public interface IPurchaseOrderV2
   DateTime OrderDate { get; set; }
which includes only one new field. It is used in

Name = “PurchaseOrder “,
Namespace = “”)]
public class PurchaseOrderV2 : IPurchaseOrderV1, IPurchaseOrderV2
   public DateTime OrderId {…}
   public string CustomerId {…}
   public DateTime OrderDate { … }

I believe that it would it be more appropriate to have IPurchaseOrderV2 derived from IPurchaseOrderV1.

public interface IPurchaseOrderV2: PurchaseOrderV1
   DateTime OrderDate { get; set; }

I asked myself,  should I repeat all properties from original in a new interface and would it give any benefits to versioning.

public   interface IPurchaseOrderV2  
   public DateTime OrderId { get; set; }
   public string CustomerId { get; set; }
   public DateTime OrderDate { get; set; }
but I was on a wrong track.
Interface is not allowed to be marked as DataContract.The reason is explained in  the answer of

XML schema doesn’t know anything about interfaces – it’s all about concrete, actual types.

Using interfaces for service contracts are recommended, however  interfaces in dataContracts are not exposed externally.
i’ve checked the article again and found that the appendix  in MSDN  actually is quite clear:
write INTERNAL implementation code in terms of the interfaces rather than the data contract classes that implement the interfaces.
I just confused myself by quick browsing instead of proper reading.