My sense is that there are two distinct matters people are trying to address when the think of "Flyweight Objects". In some languages, objects are bulky struct-like things, instead of references. Passing these chunky objects around is relatively expensive. If objects are always simply a reference to something, then this concern simply never comes up.

The more useful (in my opinion) facet (and really the one covered under "Flyweight Pattern") is where you expect to need a large number of instances of the class, but where many will likely be effectively identical. For example, rows of data from a table.

In this case, if the Class manages a pool of instances so that instances that appear to be the same are in fact the same (which means that context-dependent state must be maintained external to the object), then you ask the class to give you an object for the key "x". The class keeps track of the instances it has created and gives you the one it made a while back for that key (or creates one if necessary).

I meditated on this a couple years ago at On Flyweights... (with sneaky segue to data modeling), and I think my thoughts still stand.