Leveraging relationship-derived-virtual-property fields for DA sometimes involved an onStore script to turn the JsonValue encapsulation of individual record(s) populating these fields with (a) scalar(s). These scripts became more complicated because relationship-derived-virtual-properties are only re-calculated as necessary, requiring onStore script logic to distinguish between processed/un-processed properties.
The following scheme will be implemented for the organizational data model:
If only a single field in referencedObjectFields is specified, then this field will be included, 'bare'(i.e. not in an object, with both _id and _rev), in the virtual property field, either in the array, if the virtual property field traverses a non-singleton relationship, or directly, if only singleton relationships are traversed. So if only '_id' is specified in referencedObjectFields, then effectiveAssignments could look like ["id_1", "id_2", "id_3"] or , and effectiveManager could look like "my_manager_id" or null.
This would also mean that if the single field specified in referencedObjectFields was an int field, we could have [1,2,3] or  (non-singletons) or 1 or null (singletons). (I have not tested this, but this is my expectation.)
And in order to not break backward compatibility, this new behavior will only be toggled by the presence of some state in the queryConfig config object - something like "flattenSingleFieldProperties" : true/false.
And likely, this functionality will be implemented as a map/reduce function to be applied to relationship-derived-virtual-property fields, a function whose semantics might be specified by the user, so that this existing functionality can be extensible.
This Jira covers implementing this functionality, and updating the relationship-derived-virtual-property functional tests to test this functionality.