I've been going back and forth on this, because I can see the advantages and disadvantages of each option. However, I thought I'd throw some additional thoughts out there.
Apparently there is a Windows limit such that file paths (not just file basenames) cannot exceed 260 characters. That seems fairly long, but I could see fully qualified names hitting that limit if the form contains enough nesting and uses long enough names.
Given that, maybe there is a case to be made for continuing to use partially qualified names in the way that Briefcase did before 1.11. The partially qualified names are shorter than the fully qualified ones, so they are less likely to run into the 260-character limit. If we haven't heard of users running into issues with that limit, maybe that means that partially qualified names have tended to be short enough to avoid it.
Because partially qualified names include some group names, even if there are two repeat groups with the same name (which itself should be quite unlikely), there will be an issue only if the repeat groups either don't have parent non-repeat groups or have similarly named parent non-repeat groups. Partially qualified names don't protect against all cases, but compared to unqualified names, I think they make duplicate filenames less likely.
If we can expect older versions of Briefcase to be in use for a while, I do think that means that if we change the filename pattern, then downstream tools will have to account for both the old pattern and the new pattern. That may be an advantage to continuing to use partially qualified names, because doing so wouldn't require changes to downstream tools.
In the case of odkmeta, the output of odkmeta is a Stata do-file (a Stata script) to import the CSV files. The CSV files don't have to exist when odkmeta is run, but only when the do-file is run.
That means that searching for the correct file (or otherwise accounting for the two patterns) would have to happen in the do-file. I think there's no issue if the internals of odkmeta get more complex, but I think there are downsides to increasing the complexity of the do-file, because it makes it less likely that the user will be able to understand it or debug or modify it. I think accounting for both patterns would increase the complexity of the do-file, probably not hugely, but in a few different places.
All things considered, I would probably lean toward continuing to use partially qualified names. I think it'd still be a good idea to check whether Briefcase would generate duplicate filenames and fail if it would. And if we hear about any issues, maybe we can circle back to this question then. But they help avoid the 260-character limit, provide limited protection around duplicate names, and don't require changes to downstream tools, so even though they're a bit of an unusual pattern, I think they have advantages.