We could have:
  
  Object subclass: #Singleton
     instanceVariableNames: ''
     classVariableNames: 'UniqueInstance '
     poolDictionaries: ''
     category: 'Kernel-Classes'
     
  current
     UniqueInstance ifNil: [UniqueInstance := Singleton basicNew].
     ^UniqueInstance
     
  new
     self error: 'Use current to get an instance of Class ' , self name

I'm not understanding how this would work as a superclass.  current should
return the object of one of Singleton's child classes, not the object of the
Singleton class (which shouldn't exist anyway given that Singleton should be an
abstract class).  Because I don't know of a simple way of calling down an
inheritance hierarchy, I'm thinking that Singleton>>current can best be
implemented as a subclass responsibility, which runs counter to factoring
common code in a superclass (or suggests that there may not be a useful amount
of factorable common code among singleton implementations).

  In case not, why not

Assuming the previous objection can be dealt with, the need for a class
variable per singleton class causes a problem.  For example, if I make both
SymbolTable and TypeTable subclasses of Singleton, then the return value for
both SymbolTable>>current and TypeTable>>current is set by whichever of
SymbolTable>>current or TypeTable>>current is called first, an unhappy event
for the current method called second.

There's a few ways to fix this.  One is move UniqueInstance down into the child
classes too, at which point we can end the discussion as to why there's no
Singleton class in Squeak (assuming there isn't one; I don't know for sure).
Another is to implement a registry of Singletons (Design Patterns, page 130),
which is a loss if you're interested in making code simpler and smaller.