Racket: I'm willing to accept this change in Vim's default ftplugins, but I'll probably keep it upstream for now. When the newer mechanism is available, I'll convert. That said, is #17145 still moving?

Effective use of 'formatprg' requires both an understanding of the
specific capabilities of the formatting tool and Vim's formatting
commands. This is overly burdensome for some users.

Those who prefer predictable behavior use gw instead, which is almost always what was intended when gq is used. The latter is likely just better known as it came first. Without formatprg/expr, what's the value provided by gq over gw ? So I'd rather argue for the opposite coupled with a recommendation of gw

While I think that Vim shouldn't have to chase the ecosystem (development tools) of every language, hence Vim shouldn't set formatprg by default for any languages without one yet, wouldn't this PR be a breaking change? People already familiar with formatprg of those filetypes will suddenly be presented with something as dumb as gw.

This PR is simply following through on the decision already made in the referenced PR (see #18650 (rust.vim: stop setting formatprg to rustfmt)).

I agree with this approach in principle. However to not surprise users too much, let's merge this after the release.

For what it's worth @ychin 's proposition of an opt-in in #18650

Alternatively, we could have a general let g:enable_filetype_formatter=1 type setting in vimrc that will turn on all formatprg / formatexpr settings in all file types by convention. The reason why this may make sense at least within formatting's context is that a user who is aware of this should already know that gq is specifically designed for using these options, and gw is for using Vim's own formatter

is in-line with existing (inofficial) standards such as g:no_plugin_maps and helps showcase gq's capability to respect syntax. (In an ideal world, gq would likely do what gw does and gw respect formatprg, but by now users mainly expect gq to add line breaks to comments.)

I agree with this approach in principle. However to not surprise users too much, let's merge this after the release.

The ftplugins for go and gleam are adding the setting with this release like rust. So, it would be a good idea not to add it only to remove it in the future.

The awk ftplugin has also generated complaints.

I'm willing to bet lprolog and modula3 aren't getting too much use and the formatter for the latter is quirky enough that anyone using it probably knows what they're doing. racket is probably the only one likely to cause surprise if it's removed.

I'm not sure what difference it makes if users are surprised this release or the next, other than pushing the complaints out into the murky future. :)

Okay fair fine then

Not sure if I follow all the details, but what about adding a guard if empty(&l:formatprg) | &l:formatprg = ... | endif ?