The PMC is scheduled to meet next week and I guessing/assuming we will be discussing the names.
The point of this thread is for brainstorming so at least I am personally not trying to advance one over another at this point.
The ODK has been around for some time, and some brand awareness comes with that. I’d suggest you keep the ODK aspect with both, but differentiate their names by something other than generational number. How about their unique characteristics? How about something like Stand-Alone ODK vs. Modular or Extensible ODK? Something that gets to the heart of their unique values and the goals of their architectures.
How about defining the criteria first? Google’s logo, the whimsical animations on their home page, the name of their android systems ( Lollipop, Oreo) say “unabashed childlike fun.” Apple’s logo and the names of their operating systems like (Snow Leopard, High Sierra) say “wild and natural beauty.” With this approach, pick something like “hope” or whatever makes you think of ODK. Then pick the names.
From this link, the symbols are Swallow (the bird), Anchor, Dove. Hope - Wikipedia
ODK Swallow
ODK Anchor
ODK Dove
From Emily Dickinson’s poem , “Hope is the thing with feathers” “Hope” is the thing with feathers by Emily… | Poetry Foundation
ODK Feather
Perhaps ask the community to submit their symbols for hope or their country’s symbols for hope to complete the list. The suite names then will always follow this convention.
In addition, when it comes time to draw up an icon, it will be easier to visualize a “Dove” as opposed to something like ODK MegaPlatinumXXL.
Thank you 
to everyone who has contributed to the brainstorming process. 
Please keep your suggestions coming if you have any!
At the PMC meeting we discussed the timeline for wrapping up the public brainstorming. From the PMC meeting notes:
Timelines:
- End public (brainstorming) discussion Sept 31.
- Oct 1 - Oct 10: Waylon: Will mediate the process of taking suggested names to shrink the list with ODK 2 devs and PMC.
- Oct 11 - Oct 15: Public forum discussion of the narrowed names. ODK 1 TSC will be tagged
Sigh, and I was thinking “ODK-X” would be a great name, for ODK 1! ‘X’ is sexy, sufficiently vague-yet-mysterious to be interesting, and - for those in the know - acknowledges ODK’s true heritage: XForms! 
Which still leaves unanswered what best to call it’s recent cousin (and I’m pretty sure the obvious “ODK-Y” won’t garner too many votes. lol). “ODK-Flow” perhaps?
We always focus on the differences, perhaps we should be more inclusive, focus on the similarities and call them both ODK-X … This will certainly add back an element of mystery 
Sync was the distinguishing component drew us to ODK 2.
Later, we began to build applications on top, I think in the way that led @Jeff_Beorse to suggest ODK “Platform” Suite.
I’ll put another vote forward for ODK Sync.
ODK Platform has some appeal, but the specificity of ODK Sync trumps it for me.
But is “sync(ronization)” the fundamental distinguishing operational feature between ODK1 and ODK2 architectures? The problem for it - or almost any other term for that matter - is that by implication it suggests the alternative, ODK1, does not (and cannot) support said feature (!). But, realistically, there’s really nothing architecturally in the ODK1 stack precluding automagically synchronizing form submissions, form definitions, what-have-you between the backend (Aggregate, Central) and user-facing frontend (Collect, Enketo), but for a few background threads.
I can certainly understand from a development perspective that the integrated application+data ODK Sync is hugely convenient and attractive, but I’m not convinced it quite gets to the core of what fundamentally differentiates these two different architectures… If its any colsolation, I’m still struggling to nail down - into a single word - what the core difference is. 
Just my $0.02.
@bengreen So now I’m genuinely curious… if Collect were able to, say
- automatically push up partial survey updates to Aggregate, while the form is still being filled in (either in real-time if have live network connection, or batched when app determines it is back online)
- automatically retrieve form updates from Aggregate in background (either by regular polling, or via push notification upon and new form upload)
- automatically update the app itself (via existing Android auto-updates)
would that change the playing field between ODK-1 and 2 for your target usage?
(1) could - at a very broad brushstroke - be reduced to a something along the lines of an “IF EXISTS UPDATE ... ELSE INSERT...” SQL statement. And (2) would only require a background thread regularly polling Aggregate’s form list for new versions and downloading changes as needed, or some additional code to respond to push notifications.
My only suggestion here is to name it something meaningful to the audience of potential users seeking a solution. A lot of times as engineers, we think of why things are different in the architecture or or implementation, but those differences are lost on the user base who are also trying to figure out why one should be chosen over another for their particular use case.
@Xiphware Good points.
What ‘sync’ means in our operations is ongoing cyclical sync of forms to devices (we build forms in Tables) and the subsequent syncing of completed form data back to Aggregate.
It’s true for us that that has always been attractive, and we’ve successfully built on that premise.
I didn’t mean to present from the development perspective. But perhaps the development perspective is an important distinction, as ODK2 is extremely powerful for teams with development capability?