The design of an interfaces should be based on the components that will use it (consumer), and on the components that will implement it (implementor).
Would you ever want to write a class that only draws a circle, but not any of the other shapes?
Maybe you have a DefaultGeometryManager with hardcoded algorithms for each shape. But the one for circle is slow or flawed. You have a dedicated highly-optimized library for circle-drawing, but you don't want your DefaultGeometryManager to depend on this library.
You could inherit from DefaultGeometryManager and override the circle method. But this approach has limitations. E.g. if you later want to do something similar for another shape.
So you could split up your interface, and let IGeometryManager inherit from the individual interfaces. Have a CompositeGeometryManager implementing IGeometryManager, which delegates each method to a dedicated implementation.
Thanks to LSP, the DefaultGeometryManager matches the requirement of each of the dependencies of CompositeGeometryManager. So:
defaultGeomegryManager = new DefaultGeometryManager();
circleCreator = new OptimizedCircleCreator();
geometryManager = new CompositeGeometryManager(defaultGeomegryManager, defaultGeomegryManager, defaultGeomegryManager, defaultGeomegryManager, defaultGeomegryManager, circleCreator);
If the method signatures for each shape were the same, you could instead have just one interface IShapeCreator. But I would say this is not the case in your example.
A decorator class is a consumer and a provider at the same time. Usually it only cares about one of the methods. Decorators are easier to write for small interfaces.
Mocking and testing.
An interface with fewer methods is obviously easier to mock.
Consumers: Known / internal
If your interface is only meant for consumers inside your library, which you control yourself, then it is generally ok to have dedicated interfaces with only those methods that are actually needed. Or, as you suggest, one method per interface. This approach is great for internal refactoring.
Consumers: Unknown / external / 3rd party
If you want to provide a public API, then you need to design for consumers that you don't know yet. Probably you want to provide richer interfaces, which are more comfortable to use. With a "1 method per interface", 3rd party code would have a hard time delivering the exact component to each consumer.
On the other hand: If a consumer library wants to rid itself of a library it depended on, and provide the same functionality by itself, then the richer interface becomes a burden.
This, and the mocking argument, could be seen as an argument for "1 method per class" even for the public API. But I would say the overall usefulness and comfort of richer interfaces still make them the preferable choice.
Some developers will complain that the library becomes really big (in number of files / classes / interfaces), with all your one-off interfaces.
Also, after a lot of internal refactoring, you will see leftover interfaces and classes which you no longer use, but cannot remove for BC.
If you work in a team, this may be a turn-off for your co-developers. But while it can be irritating seeing so many interfaces and classes, it does not really give you structural problems.
I personally find this much preferable to having the same logic within one class.
If you work with a 1 method per class apoproach, you want a real simple generic naming pattern for classes and interfaces, because you will have to come up with a lot of names.
The naming pattern should prevent future name clashes and ambiguities.
You should avoid vague terms like "Manager" or "Kernel", but instead let the names somewhat reflect the name of the method.
Method names should be distinguishable between interfaces, so you can later combine interfaces via inheritance without nameclash. E.g. if you had ICurveCreator::create() and ILineCreator::create(), then you would get a nameclash in your IGeometryManager.
If your language supports generics, you need to write fewer interfaces.
A reasonable approach is to provide some rich, composite interfaces for your public API, and smaller interfaces as contracts between your internal components.
You could go down to 1 method per class, but it is not always necessary.
You could start all your code with a 1 method per class approach. Development can be really fast this way, because you avoid a lot of decisionmaking, and your IDE has a really easy job autocompleting. You can still scale up later, and recombine individual components.
Or you start with the bigger interfaces, and then gradually split them up as you see fit.
"the next step is Functional"
This is right, in theory.
But it depends how well this is supported in your language. You might lose a lot of "strict typing" features of the language.
E.g. in PHP, the language features for interfaces and classes are richer than for functions. Modern PHP does have anonymous functions, and a "callable" type. But a parameter type hint cannot distinguish between signatures.
And even if it would: What if the required signature is just "a function that returns a string, with no parameters". This can still be quite arbitrary. A signature is a technical contract. An interface is a combination of a technical and a semantic contract.
Value objects can mitigate this problem, and make your signatures more specific.
Also, classes provide more comfortable (though more verbose) ways to organize instance variables.