These are not regular setters and getters. They are 90% side effects and 10% setting the value while there’s not to my knowledge any common use case for ever getting the value. Furthermore, the method would also behave in odd ways as a setter since text.setValueSignal(signal); after a previous text.setValueSignal(signal); throws an exception about a binding already being active.
There were some discussion about different naming strategies in Thoughts about conventions and naming for binding signals to components? and that discussion was leaning towards the “bindXyz” convention. Do you think there was anything we omitted at that time?
I fully agree over a slightly longer time perspective. For now, the focus is on getting the bare necessities covered for releasing with Vaadin 25.1 in March next year. Providing a fully signals-based form binding solution will not be backwards compatible which means that it would be a completely new API while keeping Binder intact.