@LefterisKoumis to clarify further on your questions,
* We do have it documented, it's just not as clear and easy to quickly find as I think it should be. The web map specification has a blurb about it at https://developers.arcgis.com/web-map-specification/objects/formFieldElement/, in addition, if you look at this sample https://developers.arcgis.com/javascript/latest/sample-code/widgets-featureform-async/ it has it written in the description. I think it should be easier to find so will add an additional notice in the actual API reference. Regarding the above referenced sample, take note that all field elements that reference a `valueExpression` have editable set to `false`. This is a requirement for working with valueExpressions.
* When the `formInfo` was initially implemented, we did not have support for calculations. It was very basic. You could show fields or groupings of fields. The fields could be referenced and you could control whether or not you want to require or make them visible or editable with a simple boolean. This is where the original `editable` and `required` fields were used. These properties were carried over from the legacy FieldConfig class that has since been removed in favor of using the FieldElement. With the advancements made in the form to support calculations for field visibility, editability, requirements, and value expressions, we decided to deprecate the older properties of `editable` and `required` in favor of working directly with their expression. We still honor the deprecated properties for those older maps created before this affect took place. Moving forward though, any new web maps that get written out with form configurations will reflect the expressions
Although you may be able to set editableExpression directly to false, it is not the tested and recommended way using a named expression. We recommend setting it to an actual expressionInfo which returns a value of false. I know that that can be cumbersome for small booleans, but just wanted to make sure you were aware of this if you notice any weird behavior.
* You asked about "after you create or edit a feature, it would be great to return the editor to its original state and stop the create/edit of other features." This is a result of some worfklow refactoring that needed to happen to support the feature to feature relationship editing. It does not break, but can be irksome if not expecting the UI update. If you click on the back arrow, it should take you to the initial state. We intend on addressing this for the next release.
I intend on getting this documentation cleaned up based on some recent feedback, this including removing the deprecated `editable` property on the FieldElement.
Thanks again for the input, and please reach out if you have any additional questions.
-Heather