Thanks for the comments! +1 comments as you have added @mathieubossaert are super helpful because they will help with prioritization. @Remy_CLEMENT if you have other thoughts on the specific changes described in the docs, those would be much appreciated too.
And I also want to be super clear that most of the awesome proposals so far are from @zestyping and @Ivangayton who have been experimenting with some of the changes already. I have not yet been personally involved in building forms or supporting deployments that use traces and shapes so my impressions are limited to issues I've noticed from toy forms. I see geo as a huge area of potential but don't have a ton of knowledge or experience myself.
A generic geowidget that lets the enumerator decide what and how to collect values is an interesting idea. The general ODK model is to structure forms as much as possible to reduce variation in data collected. As I understand it, the goal is to get reasonable data even if enumerators don't understand the problem domain well, have low literacy, low technical experience or aren't trustworthy (seriously, this happens!).
I'm having a hard time imagining a case where any of a point, a line or a shape would satisfy my data needs but I probably just lack imagination! Could you please describe a scenario when you'd like to have a generic geo widget? Also, if it's important to you, it would be helpful to have it in the proposal doc. Please request write permissions and I'll give it to you. My guess is that once we've cleaned up the code and made other improvements it wouldn't be a big deal to introduce a generic widget if there's need for it.