The "discovery" of space-like double width characters is interesting but I don't think it changes anything. We already knew that there are many characters with width > 1 that could potentially be used as separators. However, being used as a separator doesn't make it automatically eligible for being a fill by any stretch of imagination. The design std::format and other facilities it is based on doesn't meaningfully work with such characters. To understand why let's look at types supported by std::format and observe that pretty much all the arguments do not have width which is a multiple of 2:
bool: is printed as true and false with the width of the latter not being a multiple of 2; only localized format can potentially be meaningful
numeric types, pointers: using arabic numerals, cannot be meaningfully restricted to multiples of 2 even in localized format
character types: char cannot be meaningfully restricted to multiples of 2
string types: can potentially be restricted
chrono types: cannot be meaningfully restricted to multiples of 2 except for potentially some locales (although the response from the actual users was negative!)
As we can see pretty much the only case where a double width fill makes sense is when the arguments are restricted to a small subset of inputs in a localized environment. Although we could invent some handling of the mix of double and single width inputs, as Tom's analysis clearly showed none of the solutions is satisfactory (they are basically hacks).
All of this suggests that this functionality doesn't belong to std::format but at most some localization facility which works exclusively with double-width inputs. It could potentially use std::format or formatter specializations as part of implementation though.
The fact that it would introduce a nonzero penalty for the common case violating the "don't pay for what you don't use" is also worrying. Fill, width and alignment have to be supported by all formatters and therefore even seemingly small changes can have significant costs. It's particularly worrying to pay for something which is clearly broken for most inputs.
Therefore I continue to be strongly opposed to introducing this novel design by committee to std::format to the extent that I'm actually willing to write a paper arguing about not doing this even though it's a huge waste of time that distracts us from doing things that actually matter.