should "space" be moved to gid1 in the glyph order, and if so how?

https://github.com/googlefonts/glyphsLib/pull/1038 (released with glyphsLib 6.9.3) moved the .notdef and space glyphs as the first two glyphs even when an explicit glyphOrder custom parameter was present; an additional (hidden) custom parameter would be needed to disable any such reordering.
This was apparently done to match Glyphs.app, although I haven't been able to consistently reproduce this behavior.
Therefore I decided to revert it with #1044 at least until we understand this better, and to avoid sudden changes to fonts that were perfectly working with previous glyphsLib 6.9.2. The glyph order affects all glyph-related tables and may impact hinting and other workflows that are tied to the glyph indices.

Everyone agrees .notdef must be first for the first glyph by definition can't be cmapped (gid0 means no unicode). But space as the second gid1 is not as universal requirement and was only added because of a bug or rather implementation detail in an older verisons of Windows related to color fonts with COLRv0 table:

https://github.com/MicrosoftDocs/typography-issues/issues/346
https://github.com/googlefonts/gftools/issues/609
https://github.com/googlefonts/ufo2ft/issues/880

I am of the opinion that there should be no reordering if an explicit glyphOrder custom parameter is defined in the source.
ufo2ft only places the space after .notdef if an explicit public.glyphOrder is absent: https://github.com/googlefonts/ufo2ft/pull/881

However, if Glyphs.app does override the user provided glyphOrder, then glyphsLib should probably try to mimic that, but we need to understand exactly how this works first.

glyphsLib always sets a public.glyphOrder in the exported master UFOs; when no glyphOrder custom parameter is present, I believe it uses the ordering of the glyphs in the source file (which in turn comes from Glyphs.app itself if I am not mistaken).

We could also leave things as is and do nothing.

Maybe ufo2ft could warn when building COLRv0 font if the second glyph has any contours so the font developer can decide for themselves.

Start by reviewing the behavior discussed in PRs #1038 and #1044, then compare the linked ufo2ft behavior and the Glyphs.app and Windows color-font references. The work is not yet scoped to a specific file or implementation; it is done when the expected glyph-order behavior is established and an agreed change or decision is recorded.

Written by the indexing model from the issue text.