I find the locale-specific aspect of this a bit worrisome.

Also I don't really have experience with glyph substitutions. Do these require that the editor support and enable them?

Yeah, it's not a slam-dunk obvious feature. Just take a look at be5invis/Iosevka#453 to see a lot of quibbling on what would be the right way to show digit-grouping. We can make multiple ones with different choices, I guess, but that would mean that much more maintenance. As I currently have it, there's a single glyph representing the comma which is referenced in all the digits, and you can change the shape of that as you like; maybe something neither a comma nor a period would work best.

Some things support glyph-substitutions and some don't. I've tried out a LOT of terminal emulators, and a few do (kitty, pterm, a few others), many don't. Good word-processors give you control over enabling and disabling these features; I think as it's done now it would be enabled by default—if the software you're using supports it at all.

I find the locale-specific aspect of this a bit worrisome.

I've been researching this recently, and to my understanding the recommendation for fonts is that they offer something like different feature tags for different regional typesetting rules (let's just say digit grouping is typesetting for now).

What this means is that while the font might be able to implement all the different grouping styles and delimiters for all the different languages, what it's expected to do is provide is the means for software to activate the appropriate rules without the font trying to deduce their applicability automatically (even though I think the font can deduce this in theory).

I did a half-baked solution which offers font-features: dgsp to add spaces every three digits, dgco or dgcd to add commas, and dgdo and dgdd to add dots (which is a terrible idea because it collides with dot-for-decimal, as required by much computer-formatted output, so I also made it replace dots with commas and it's down to the software to apply the tag responsibly [eg., in CSS markup for tables, but never for regular text]).

I think it's a thing that fonts can offer but leave turned off until the appropriate software configuration switches it on. My personal preference is to offer thin spaces as the baseline implementation, because this is in line with international standards and scientific journals, and offer others as personalisation or regionalisation upon request.

Well, this feature might be useful, but some (most?) people probably do not want this.
At the moment it is a CALT which is always active; this should be a SS (Stylistic Set) instead.

Example: No way to turn it of, no option to disable this with Scribus, the application that supports tons of font-internal options.

Font feature is empty, everything is applied by default

Compare with Iosevka, mentioned above, that has a lot options and the user can decide:

About locales...

The PR assumes a locale where decimal separator is dot and thausends separator is comma,
but in a lot countries the reverse is used and this breaks:

And there is nothing specifically enabled with the font. This can not be the default.

Closing this while we find a locale independent solution.

Sounds good to me. My script is pretty basic, and rides roughshod over local conventions; I understand why this might not be acceptable. We could do this as several different style-sets if preferable, maybe with none of them being the default (one of the problems with all this is that you can't always set the "optional" OpenType features when you want them.)

The downside to using thin-spaces for this is that it amounts to shifting the glyphs around inside the character box, which is okay until you're actually typing, and it looks like the numbers you already type are restlessly jumping around... Depending on how much that bothers you.

Thanks for the consideration, though.

I've been using a font patched with dancing digits in my terminal for a while, now, and I've got used to it. There are some other quirks too, like if the text changes colour in the middle or wraps around a screen edge then that perturbs the digit grouping; but overall I've become dependent on it.

I think the proper path to standardisation for a feature like this is to register font feature codes to implement the twelve or more standards (comma/dot/space, fours/threes/twos-and-threes) and then leave it up to software to enable the features according to locale configuration (or to do it manually if the font doesn't support it, I guess?).

The patcher I linked can do some of that to a font, but the tags it uses are not registered and no other software supports them.