From an extension, you can only change the base EDT's stringsize, not a child EDT's. The restrictions are the same as they were with over-layering. The main reason is that this "hierarchy" of EDTs is an actual feature used in tables. Changing the stringsize of one of the child EDTs could cause data corruption in any data structures were different child EDTs' values can be stored in a field that uses the parent EDT.
A typical example of this Inventory Transactions that store a generic "order number" using the NUM EDT. This field could end up getting sales order numbers, purchase, production, etc. that all use EDTs derived from Num. As such, you can't increase the sales order number without increasing NUM or you'd have data problems.
The main reason people don't like increasing NUM in this example, is because now all fields using an EDT derived from NUM actually get a larger string size which can be irritating due to large forms controls, report layouts, etc.
We're working on a new feature to address the need of extension without causing data problems or other functional areas' UI being affected. This new feature will be similar to how Real EDTs handle database precision versus NoOfDecimals in UI, and how and when it allows EDT extensions. Will provide more information and documentation when this feature will become available.
