You're not the only one to ask. You're misled. This is not a good idea.
Here is what you WANT:
[1] When writing your source code, you want _GUIDANCE_: Best case scenario, you want the following guidance: Which methods should not be called again because you already called them (so, they are set-once builder methods that you already called), which methods must still be called before you can continue to calling build() (mandatory builder methods that haven't yet been called), which methods can still be called but aren't required (set-multi methods such as the ones @Singular makes, or builder-setters that have defaults).
[2] During writing it and afterwards (during compilation, your CI tool, your IDE's problems & warnings list, commit hooks – one or more of those) a warning or possibly error indicating something that's wrong with your builder call, such as omitting a mandatory prior to calling build(), or calling a set-once method multiple times.
So, you should aim for precisely that. No more, and no less. Your explosion of types gets you this, in a really silly way: You get a ton of types, trying to send half-built builders around other code is insane (you need to start putting the intermediate interfaces into your APIs), you still see all the java.lang.Object methods in the mix, you have no good way of dealing with optional fields, you are forced to call the mandatories in a specific order and have in fact eliminated the ability to split up the code for building across multiple different methods.
There's absolutely no reason you can't just get what you want: The IDE can and should be specific. Your autocomplete dialog should render in bold all mandatory calls, render in normal all optional available calls, and render in grey any calls that exist but which you should not make (build() if mandatories aren't covered yet, for example). The bold ones should be at the top of the box, of course. That's what you want. This will also then work with ALL builders already in existence. Potentially they'd have to add some annotations but that's API-wise backwards compatible.
Given that this is the option, the crappy half-baked way to get this via @StepBuilder is not acceptable.
Also, note that the notion 'I return a PersonBuilder object whose name() method has already been called' is something that the StepBuilder would convey via the notion of a PersonBuilderAfterStepName. But the checker framework (
https://checkerframework.org/ ) does it right: Types can carry tags (for example: I return a String and it will not be null; the nullity is a tag), and the checker framework lets you add a tag to your 'PersonBuilder' as it shows up in for example a return type: name() has been called. You can annotate your build() method to be allowed only if the receiver is of type 'PersonBuilder for which name() and birthDate() have been called.
We're working on lombok generating these markers so that you can then use the checker framework for linting checks. It's then up to IDE builders and/or plugin builders to add the guidance on top of that.
THAT is where the effort to work on this problem should go: Linters and IDE plugins. NOT in generating 18 million interfaces.
TL;DR: Project Lombok's official position is that we will not add this, will deny PRs, and consider the pattern a half-baked inappropriate solution to the problem; instead, look to address this issue by making the tools (IDE and linter) aware of the builder pattern. Lombok will support any such linter and/or IDE tool as best we can, and we will consider any PR that adds such support. In fact, we're working on one for the checker framework's take on this now.