@danbjoseph happy to join for that if it fits @tomsmyth's agenda. I put some reactions to various threads at Selecting a map feature to collect data about - #13 by LN.
I'm seeing a v1 emerge that directly addresses @danbjoseph's second use case. This one matches a lot of the others that came up in the thread. From a user perspective, it would enable attaching a list of features to a form definition and having those features be displayed and tappable on the existing Collect form instance map. Tapping on a feature would launch a new form instance with pre-populated values from the feature data. With Enketo, the selection would likely happen in whatever the host application is (e.g. Central) and then the rest would be the same. The major question is whether this covers enough ground. Relatedly, is it worth doing separately from the broader entity-based project. It would be good to also get some opinions on what to do about the Ona thread and related library at Ability to load locations into the geowidget to guide data collection.
I think it's premature to go deep on the technical side but I know it can be helpful to look at something concrete so here are some quick notes. I'm thinking it'd be possible to write XPath queries on the feature data simplified in XLSForm to something like ${feature#properties/type}. There'd be some standard for defining features and their IDs (e.g. https://tools.ietf.org/html/rfc7946#section-3.2). The form instance map would have knowledge of that data and would render every feature it contains. Initial ideas for how that could work would be to render the features in all secondary instances with extension .geojson or to have a reserved secondary instance name. All of those features would be tappable. Tapping a feature would launch a form instance with the tapped feature ID (e.g. in a context virtual instance as suggested by @martijnr).