Jacob Keller [off-list ref] writes:

I think the key point is that this "in the future" is referring to "a
future version of git will make this an error"

This might be better if it said something like "The pull was not
fast-forward. In a future version of git you will need to specify
whether to merge or rebase, using pull.mode"

Oh, I've actually been assuming that the current "warn but go ahead
anyway asssuming the preference is to merge" can just be declared as
a bug (iow, there is no need to say 'in the future'---we'd fix the
bug right away).

or something similar. In theory, this warning will go away once that
future version of git changes so that pull.mode defaults to ff-only.

The difference being that a warning will allow the command to continue
doing the default of today (merging), where as an error will stop the
command essentially just after the fetch portion finishes, without
changing the branch.

Yup.  If we want to take things slow, that is fine by me as well,
but I am not sure if that is even necessary, given how annoying the
existing "loudly warn but still go ahead" behaviour is, and how easy
for existing users to have squelched the annoyance by choosing
between rebase and merge already.  I've always assumed that any
existing users who started using Git in the past several years have
already set pull.rebase to one or the other value and they won't be
affected by fixing "git pull" to just error out.