Generic message in Elm for simple model updates
I think the general consensus is to avoid functions in Msg constructors when possible.

The one certain thing that will break is the Msg history import/export of the Elm debugger, since functions cannot be serialized.

Evan included this comment in his Sortable Tables example:


  One of the core rules of The Elm Architecture is never put functions in your Model or Msg types. It may cost a little bit of extra code to model everything as data, but the architecture and debugging benefits are worth it.


Here's some commentary by Zoul on Discourse:


  Generally speaking, in Elm you model an app with explicit state modified by a pure function based on messages with clear semantics. This makes it very easy to reason about the state changes: it’s quite obvious what state the app is in and what state transitions lead to this state.
  
  Once you start using functions in messages, this model gets much more powerful, but much less transparent. You lose the clear distinction between data and code – the messages no longer describe what you want done, they implement a part of it. You cannot see the behaviour just by looking at the update function anymore. And comparing or serializing the messages gets more complicated.
  
  In the end, it’s probably not worth it.


Besides breaking the debugger for yourself (and for others, in case you publish a package violating this principle), I don't know of any kind of language problems you may run into if you go down this path, and the above comments are the norm for this question: vague warnings about never putting functions in messages but not much specificity into the why not of the question besides the debugger issue.

But in the end, if the language designer says to never put functions in your Model or Msg types, in bold text nonetheless, I'd defer to their judgment on the matter.