I would change these into a list of handlers. Like in https://github.com/patternfly-java/patternfly-java/blob/main/components/src/main/java/org/patternfly/component/form/TextInput.java#L102

Or even better re-use and expose the already existing lists of keyup and change handlers of the TextInput component.

Ok, will try to experiment with it.
One thing is that I implemented the onPlus/onMinus handlers bit differently - because they pretty much by default handle the default incrementing/decrementing by 1. So having a List of (plus/minus)Handlers might be bit confusing => if you create a custom increment by 10 in the final it will increment by 11.

I guess in theory, I can have something like a custom flag that removes the default handler (increment/decrement by 1) - but maybe that could be a bit confusing for the user. What do you think?

Yes, you're right. I think the built-in default should be hard-coded and should not be configurable. Then we could have a list of handlers that can be used to get notified if the user clicks on the +/- buttons.

Not really sure If I understood the comment properly, can you elaborate a bit?

Oh, I think I understand, so we will have List of onPlus/onMinus handlers and by default (the incrementing/decrementing by one) should be the first and cannot be removed.

All the other custom handlers should be appended to the List and will work like a pipeline?
So the custom incrementing by 10 is expected to be 11 (in a pipeline's context).

What if we add a builder method like

public NumberInput step(int step) {
    this.step = step;
    return this;
}

and then use NumberInput.step (which is one by default) in the built-in increase/decrease handlers.

that could work ;)

Actually, I did not go for the int step, but rather a UnaryOperator<Double> i.e.:

public NumberInput plusOperation(UnaryOperator<Double> operation) {
    this.plusOperation = Objects.requireNonNull(operation, "operation must not be null");
    return this;
}

public NumberInput minusOperation(UnaryOperator<Double> operation) {
    this.minusOperation = Objects.requireNonNull(operation, "operation must not be null");
    return this;
}

public NumberInput operations(UnaryOperator<Double> plusOperation,
        UnaryOperator<Double> minusOperation) {
    return plusOperation(plusOperation).minusOperation(minusOperation);
}

Used like:

numberInput(90).operations(v -> v + 3, v -> v - 3))

I think that this is even more flexible (allowing for doubling,dividing etc, having different operations for plus/minus).

That's a great idea 👍
The only minor change I would make is to change the signature of the operations method to

public NumberInput operations(UnaryOperator<Double> minusOperation,
        UnaryOperator<Double> plusOperation) {
    return plusOperation(plusOperation).minusOperation(minusOperation);
}

so that minus is before plus.

With that in place we could add a step method that delegates to the operations method:

public NumberInput step(double step) {
    return operations(v -> v - step, v -> v + step);
}

unit feels more like a builder method to me. Though there's something added to the number input, it's different to other add methods. Like there's no (sub)component added. So I would rename the methods to unit(...) and move them to the builder block.

Like in

The textInput.on() methods aren't what you're after. They register the handler on the TextInput.element() element, which is a <span/> element. You should use TextInput.input() to register the handlers instead. This method returns the underlying <input/> element.

that did the trick with blur