Thank you for the generous feedback & input 🙂
To make sure that we talk about the same things, its easier for us to separate the terms "user" and "author" in design discussions about R3. A "user" is someone logging into the system, using an application and not knowing/caring about how its built; while an "author" is someone building a R3 application.
I got tripped up by your suggestion and thought you were talking about an end user, not an application author:
It would be great for users who like keyboard usage if there could be some control...
Now I understand that you were talking about giving an application author control over tab indexes within their forms.
To your suggestions:
For configuring a single field to get focus on form load, it definitely makes more sense to define this on form level (instead of a toggle for each field). Because we have form states, the chosen field might not always be available to get focus however - though I would say that this edge-case would be acceptable because the field getting primary focus should usually be very important and therefore rarely be hidden. This would be straightforward, in my view.
I am not so sure, about giving tabindex control in general to authors. It would only be relevant, if the automatically calculated tabindex is wrong or unintuitive for a given form. What are the use cases, that this feature would address?
I am asking, because I´ve never felt the need to adjust the tabindex in R3 apps. Maybe you have specific apps or use cases in mind, where this would be helpful.