I'm afraid that newlines are generally not accepted by Windows numeric input fields. However, that should apply to any numeric input fields, not just tempo fields. Since tempo fields allow for fractional inputs, they have a different validation but its newline rejection is just identical to normal integer inputs.

If the newline could be rejected by trimming off whitespace, rather than completely rejecting the input that would be better IMHO.

Well as I said, any kind of numeric input field in Windows will reject newlines, and if we wanted to work around that, we would have to change the behaviour of every single numeric input field in OpenMPT. Maybe it's actually not the newline but some invisible character close to the newline that is causing the rejection, though?

Okay, I found that while newlines at the start of a pasted text are not acceptable in generic number edit fields, they are accepted at the end, which the decimal input field for tempo and various other things didn't like.
r9315 should avoid this issue, and can be downloaded from https://builds.openmpt.org/ within the next few hours.