Se você ler o livro Padrões de Projeto verá que há uma crítica quanto ao uso indiscriminado de Herança. Na verdade o livro mostra que existem outras maneiras de se incorporar ou agregar várias funcionalidades e depois conseguir incorporar ainda outras sem o uso de herança.
Lendo este livro você verá que há uma discrepância grande entre a Análise Orientada a Objeto (AOO) e a Programação Orientada a Objeto (POO).
Enquanto a AOO defende que não pode existir em código nenhum objeto que não seja representante ou modelo de um objeto do "mundo real" a POO, por restrições e questões técnicas, apresenta as figuras das classes de persistência (inexistentes no mundo real) dos DTO (data transfer objects, também inexistentes) dentre outros modelos e padrões. Além disso, em POO você pode ver coisas como sobrecarga de operadores, caso em que a AOO nem sequer cita.
Enquanto o livro Padrões de Projeto foca na POO, ignorando algumas premissas da AOO, ele também põe a herança em seu devido lugar: NEM TODA ESPECIALIZAÇÃO OU INCREMENTO SE RESOLVE COM HERANÇA.
Particularmente no caso de singletons, a herança é desnecessária, visto que o singleton, geralmente, é um objeto cheio de métodos estáticos que nada mais fazem do que prestar serviços. Sim, o singleton sequer faria parte da AOO porque ele é um objeto artificial, existente apenas no domínio da POO por razões técnicas, seja a leitura/escrita de arquivos de configuração seja a criação de objetos de conexão com bancos de dados.
Isto posto, não é necessário se criar heranças de singletons, até porque elas não vão funcionar corretamente e reimplementar todos os métodos de um singleton anula o propósito da Herança. Se precisar de um outro singleton muito parecido você pode:
Simplesmente criar outro copiando a maior parte do código e lógica de funcionamento (não é recomendável fazer isso se forem vários, se você quer fazer um código limpo com duplicação zero ou se deseja apenas atualizar um código para corrigir todos os singletons dependentes dele)
Se for o caso de manter a manutenção em um único ponto (recomendado) crie classes privadas, em pacotes, invisíveis aos programadores consumidores da sua biblioteca, que isolem todo o mecanismo e regras de funcionamento do singleton e implemente-o em forma de façade (fachada).
No exemplo 5 veremos como fazer singletons flexíveis, reutilizáveis e intercambiáveis mesclando o padrão singleton com o padrão façade.
Wazlawick, em seu livro , menciona que a aplicação, ou o objeto aplicação, que é o programa em si, sua "casca" mais externa que vai criar os outros objetos e interfaces deveria ser um singleton, e de fato o é. Mesmo que se executem várias instâncias da aplicação, no ambiente de uma única instância a aplicação em si é um singleton, e qualquer entidade ou artefato que prestasse algum serviço para a aplicação também deveria ser um singleton.
Como o singleton não faz parte das regras de negócio e da AOO aqui abordaremos ele do ponto de vista da POO e faremos uma tentativa de herança do mesmo, para demonstrar as confusões que podem ocorrer.
Neste 4° exemplo, analogamente ao exemplo 2, usamos o recurso de class vars (variáveis estáticas de classe, privadas) e acessores estáticos para criar class properties, coisa que só é possível nas modernas versões do Delphi, por isso perderemos a compatibilidade com o Lazarus.
Primeiro a classe singleton
class var _MySingletonInstance: TObject;
class var _PreparadoParaLiberar: Boolean;
class function GetInstance: TMySingleton; static;
class property Instance: TMySingleton  read GetInstance;
TMySingleton._MySingletonInstance := nil;
TMySingleton._PreparadoParaLiberar := False;
if (TMySingleton._MySingletonInstance <> nil) then
TMySingleton._MySingletonInstance.Free;
Depois o singleton derivado. Observe que é inútil criar overrides para métodos que fazem apenas "inherited".
class var _MySingletonDerivadoInstance: TObject;
class var _PreparadoParaLiberarDerivado: Boolean;
class function GetInstance: TMySingleton; reintroduce; static;  //não usamos TMySingletonDerivado para não dar invalid typecast caso já exista um singleton base criado
//* métodos que fazem basicamente inherited não precisam ser sobrecarregados *
//procedure InicializarObjeto; override;
//procedure FinalizarObjeto;   override;
//constructor Create;  override;
class property Instance: TMySingleton read GetInstance;
constructor TMySingletonDerivado.Create;
InicializarObjeto;
destructor TMySingletonDerivado.Destroy;
FinalizarObjeto;
class function TMySingletonDerivado.GetInstance: TMySingleton;
//não usamos TMySingletonDerivado para não dar invalid typecast caso já exista um singleton base criado