Is it logical to over-ride static members?

The Java language (or C#) does not allow static members of a class to be over-ridden. But what if there is a language that does?

Let us say that there is a class written in a hypothetical Java-like language

class DataSource{

  DataSource(Data data){
    this.data = data;
  }

  @override
  static Data getData(){
    return createFormData();
  }
  
  static <T extends Datasource> create(){
    Data data = getData();
    DataSource ds = new DataSource(data);
  }
}

Let us pretend that this language allows static members to be overridden

class GridDataSource
extends DataSource{
  GridDataSource(Data data){
    super(data);
  }

  @override
  static Data getData(){
    return createGridData();
  }
  
  static GridDataSource create(){
    Data data = getData();
    GridDataSource ds = new GridDataSource(data);
  }
}

You want a static method because you want it to be callable without instantiating the class, but you also want any derivative class to be expected to provide the method getData() as well as the factory method create(). For certain derivative classes you wish to over-ride getData() and for others you don't. Therefore, you need to consistently expect the method getData() to be present.

A so-called "OO purist" might say - this is not OO, redesign your algorithm to fit into OO constraints.

Forgive me a million times to be on the offensive - but first of all, who gets to be anointed an "OO purist" and secondly with what authority would such an anointed Chosen One pronounce that this isn't OO other than the few academic papers might have been read?

There should be absolutely nothing wrong with a programmer's preference as long as it is maintainable and extensible with the least of efforts. If a programmer finds this style of programming eases maintenance and extensibility - so be it. So, no debate about if this style of programming is good or bad.

The question to be answered is - is this logical or topologically sound?

At first purview, we could say that this is illogical.

1. Since the addressability of static members depend on the extension of the class, why don't you just make them class members rather than static members?
   Wrong answer - the factory method has to be static and, therefore, any method it calls has to be static.
2. The actual implemented class is not known until a class is instantiated.
   Wrong answer - that is due to the constraints of language's run-time architecture.
3. We would have to implement virtual references in the language and that would defeat the purpose of efficiency of having static members.
   Wrong answer - the run-time efficiency of static members is a side effect/benefit. The main reason for having static members is to be able to address those members without class instantiation.
4. Having virtual references designed to treat such a feature at run-time decreases run-time efficiency.
   Should the definition of OOP be constrained by the architecture of CPUs rather than linguistic topology? Why, processor makers could pander to virtualization, executable bit, etc and surely they could accommodate a little bit more? However, doesn't C# already have delegates? What about the planned implementation of closures in Java?

Such a feature is easily implemented with C# delegates, which would answer whether it is topologically possible to implement over-rideable static members. End of dispute.

class DataSource{

  delegate Data GetData();
  GetData getDataFuncton;

  // "static constructor" is run when class is loaded
  static DataSource(){
    getDataFuncton = new GetData(getData);
  }

  DataSource(Data data){
    this.data = data;
  }

  static Data getData(){
    return createFormData();
  }
  
  static <T extends Datasource> create(){
    Data data = getDataFuncton();
    DataSource ds = new DataSource(data);
  }
}

With this question settled, there should not be any more excuse not to allow contracting static members in an interface.