If I'm understanding correctly, you want to support some operations on the inner array, but not others. If this set of supported operations is general enough for a D2ArrayWrapper to make sense, then I would suggest using an interface.
For example, let's say you want people to be able to read cells and rows from the array, but not write them:
You should look into the default operator. Returning
would isolate other classes or generics from knowing specifics about what that would be.
Or pass the Empty T into DataModel so it doesn't have to have this knowledge and just compare against it.
You indeed can't inherit a static function. But if you need that static function to create an empty object, then you can also require that the derived classes implement a particular constructor.
The base class could then be, for example
public abstract class DataModel<TModel>: BaseEntity, IEmptiable<TModel> where TModel : new()
Prefer early composition over late inheritance:
The class of an object has to be known at creation, and most languages do not allow to change it later. So, if you create a transaction, it IS a Transaction (inheritance);
If the object has to change afterwards, it must be via its state: the transaction may HAVE some properties/behaviors depending on the ...
If you find yourself needing to add more data to your full inheritance stack over time, you should ask yourself whether inheritance makes sense in the first place.
It is odd for base classes to be extended that often. It defeats the purpose of inheritance and violates the O in SOLID.
You can mask that problem by wrapping everything up in an argument bundle ...