When creating a joined, hosted feature layer view using "add to definition," there is the option to calculate the value of a field using the the "expression" key. This works great as long as all fields used in the expression are within a single table (e.g., the primary table). Often though, the reason for creating the join in the first place is to streamline calculations between between fields held in different tables.
The documentation for Add to definition suggest that joins are similar in structure to SQL joins. A key paradigm in sql joins is the ability to reference all fields in the resulting table.
I propose that hosted feature layer joins should follow this same paradigm. Fields should be defined once, in a single "sourceLayerFields" property, rather then separately for the primary and related tables. This behavior is even suggested by the REST documentation in the definition of that property: "The list of fields in the newly created view of the joined layer.
I could see this potentially be solved, maintaining backwards compatibility by simply concatenating the two sourceLayerFields properties behind the scenes and then deprecating that property in relatedTables.
