I have clarified one point, it seems that Garbage Collection was an inherent feature of Smalltalk going way, way back.
So back in 1994 when the GoF Design Patterns book started an explosion of general interest in the topic, the examples were given for two languages, C++ and Smalltalk.
Material targeting a Smalltalk-only audience, around then, certainly later, and as far as I can tell even earlier, would be presuming a garbage collected environment as a given.
Material targeting a C++ audience would NOT be doing so, even today.
So it seems logically obvious that the GoF book, targeting both audiences together, would focus more on patterns that were generally useful to both groups.
In C++, garbage collection is not (generally) a thing, and any confusion about who is responsible for destroying an object is an invitation to disaster, an accident that can't wait to happen.
Many of the creational patterns help achieve loose coupling between users of an interface and the implementation classes.
This is good everywhere.
In all garbage collected languages, at least for immutable objects, the whole notion of who owns an object is pointless and not something a good developer working in client code should even be thinking about.
So "Get me an object of this type, maybe you are creating a new one or maybe not, I couldn't care less." is a recipe for disaster in C++ and quite often the smart way to do things in Smalltalk/Java/C#/Python etc. etc.
I think this is the actual reason that what seems to be generally retconned as the "Simple Factory Pattern" is ubiquitous in Java and, if I am not mistaken, basically ignored in the original GoF presentations.
It could have been presented as a "Smalltalk-only" example back then but from what I gather from material presented by Great Fans of that text, was not.
So the simplest kind of creational pattern in Java "I want one of these, yes, exactly this thing, it is your problem whether you are creating one at this time or just giving me one you already have around, I don't care" is now called a Simple Factory Pattern, if I am not confused.
Even today, this would just be a disaster in C++, and really isn't applicable there.
I am nearly certain there are other C++-isms, and in fact, things specific to 1994-vintage C++ that show thru in the GoF book, but this one is pretty noticeable to me.
I think it is the cause of some confusion in recent discussions, and I am certainly keeping it in mind.
RTFJD (the JavaDocs are your friends!) If you haven't read them in a long time, then RRTFJD (they might have changed!)
It's not exactly true that in garbage collected languages you don't have to worry about who "owns" an object. There are still objects that must explicitly be disposed when we're done using them. This is why Java has the AutoCloseable interface.
I STRONGLY recommend that you separate your provider interfaces/methods in two categories, and clearly name them accordingly:
Factories create objects but are not responsible for disposing the objects they create.
Managers may or may not create the objects they provide, but are responsible for disposing them.
Methods that create an object and don't care about their lifecycle should have a name that starts with "create" and usually be in a type that has a name that ends with "Factory".
Methods that return an object whose lifecycle is managed should have a name that starts with something like "get" or "provide". The type name should usually end with something like "Manager" or "Provider".
The proposal I gave in my previous post is something I adhere strictly to myself, and I recommend others do as well. However, the most important maxim remains: Read the frogging manual to see who's responsible for the lifecycle of an object.