Customization using overlayering is similar to customization concept used in the earlier version of Dynamics AX. In Microsoft Dynamics 365 for Finance and Operations, Enterprise edition you can only override an element in the same package where it is originally created. You also have to use higher layer than the original layer of the element. For example, if you want to override an element created by Microsoft in ApplicationSuite package which is in SYS layer, you have to create a model in ApplicationSuite package and select higher layer such as CUS or USR to override the elements.  

When you customize using overlayering original code element is copied over in model you are working on and you are technical changing that copy of code. As evident, when Microsoft release a fix or feature update and if this element is changed, now there could be conflict because you have changed the copy of that element in a higher layer. In the past several major releases Microsoft has been trying to define these code elements as granular as possible to minimize the impact of the conflict. But no matter how granular they are there will be some degree of code conflict if they are changed. These code conflict needs to be manually resolved to uptake any bug fixes or new features.

Other problem with customization using overlayering is, since it can be done in the same package where object was originally created, the entire package needs to be re-compiled and re-distributed.

The following image shows the concept of customization using overlayering. As shown in the following example the ApplicationSuite model is overlayered by ISV1 and ISV2 in ISV layer and then customer overlayered in layer CUS. All these models will compile into a single assembly. If the same object is changed by ISV and customer, the CUS layer customization wins: