The original proposal in this thread, #[non_exhaustive(pub)], seems to spell out a very common case: "I may add more fields to this struct, but I promise all of them will be public." It also seems like a more minimal change than adding ..move syntax, and doesn't require more typing anywhere you would want to use FRU with one of these structs.
It is a bit cryptic (would someone seeing #[non_exhaustive(pub)] guess what the pub means?) But it fits a common use case so well that I think it would still be worthwhile.
One way to address the readability issue is to also support writing an explicit "wildcard" field, as proposed in the original Extensible enums RFC, and allow a visibility modifier on it:
struct Opts {
pub a: bool,
pub b: bool,
pub ..,
}