Human Touch (#1)

I agree that the humanizing function is best performed by a human, at first by trial and error and after some experience with a confident working knowledge. I recall when several years ago I used Sibelius, which had a humanizing feature: It was completely disappointing!
I also agree that the same random displacement of all instruments of a section is not what happens, but each one of them plays at a slightly different time (except when the conductor lags, but it is a completely different situation)
I don't say it isn't possible to automate some decisions, but I think it is not as easy as adding random deviations to the timing of each note or to its velocity. Serious work would requiere artificial intelligence. An area where automation could help a lot is in trills, tremolos and drumset rolls, but it would require some research (by analyzing the timing and velocity deviations of human players).

Even if not completely automatic, humanizing playback (by a human!) could be facilitated if some tools were provided:

1) A relative tempo feature. Tempo indications are currently absolute and there is only one way of inputting them either with a humanizing purpose or not: the use of frequent invisible tempo marks (whose visibity and size reduction to prevent overcrowding the score with them must be adjusted one by one, or copying and pasting ). Tempo marks should be reserved for general or average tempo of a movement, section or passage, and a new type of mark, invisible and unprintable by default (though this could be changed as a preference), should be introduced. This would be relative tempo, for instance, as a percentage of the general tempo of the passage (the previous general tempo mark). It could be called expression tempo. Currently they are absolute, which makes it a nightmare to change the general tempo (I don't mean the tempo feature in the play panel but the case where I originally wrote a tempo of 120 and then I change my mind and prefer 116).

2) A tempo envelope drawing canvas. Tempo variations in human playing are at least of two types: general tempo variation, and agogic accent. In the first case, simply the general tempo accelerates or decelerates a bit. In the second case an individual note (or a few consecutive notes) is slowed down. If one could just draw the envelope or profile of the tempo it wouldn't be necessary to input the numbers one by one. The piano roll editor is where this could be impemented. Currently the tempo cannot be edited, even manually, from the piano roll view.

3) A different approach to articulation parameter control. If one reads any book on musical notation, such as Garden Read's or Elaine Gould's, there is a certain agreement as to the duration of articulations like staccato, but nothing is said about the intensity. However, for at least three reasons intensity (reflected as velocity) is or may be part of an articulation: a) Short sounds at the same intensity elicit less loudness than longer sounds of the same intensity (full loudness requires about 200 ms to 500 ms to develop, this is psychoacoustic fact); b) Because of attack slope in the soundfont the peak intensity may not be reached in short sounds so it may be necessary to compensate to prevent loss of loudness; c) Often a staccato carries not only a smaller duration but also some accent. This may be subtle and not explicitly notated. So the inspector for articulations should allow to change duration (as a fraction of the nominal duration) and velocity.

4) A different (or selectable alternative) approach to velocity offset. Currently, the velocity of a note can be controlled from the inspector in two ways: offset and absolute. Absolute is the value of the velocity itself. To my knowledge, Its only use is when importing a MIDI file. Offest offers something different from what is expected. An offset is a fixed increment, such as 10 units of velocity. When selecting 10, it means a 10 % relative increment in velocity, so if the dynamic is p, we have a general velocity of 49, so 10 % means an increment of about 5, that is an absolute velocity of 54. The difference is bearly audible. If the dynamic is f, the general velocity is 96, so we end with an increment of 10, and the final velocity is 106. The difference is more audible. Some tests I've performed with the piano patch reveal that the soundfont is calibrated so that equal velocity increments imply equal loudness (in the psychoacoustic sense) increments. That's why an increment of about 16 yields roughly equal dynamic increase by one mark: p ---> mp, mp ---> mf and so on. Currently, a fixed percent increment (so called "offset") is bearly audible at pp and quite a jump at ff. This is counterintuitive. My solution is to apply 50% at pp and 15 % at f, but clearly is a workaround, one would expect that the same number yield the same perceived accent.

5) A velocity envelope drawing canvas. This could be implemented in the piano-roll window. Many MIDI sequence editors (such as the free open software Sekaiju) have this feature, allowing slight crescendos and diminuendos that aren't worth notating.

6) This may be the most controversial and difficult-to-implement feature: A new aproach to tempo, allowing different tempos for different staves (or even voices). Note that there would still be a general (vertical) tempo ruling the general flow of the music, but there would be deviations.
I am aware that this is complicated in a notation system based on measures and governed by synchronism of the beats of all homologous measures. One way to handle this is by an average synchonism (sort of a phase locked loop, PLL, analogy) so that if an istrument or voice lags, eventually it will have to rush to compensate (so if there is sort of a ritenuto somewhere, then there must be a stringendo a bit later. How to do this consistently is a challenge, but would allow true rubatos in its most pure definition: one hand has a different tempo from the other hand. A parameter to control this would be the maximum desynchronization allowed, measured either in MIDI ticks or a suitable short musical figure like a 32nd note. This would be an equivalent of the maximum allowed phase displacement in the PLL analogy

You'll have the same issue with any graphical plugin then, in both MS2 and MS3.
You'll need to find a graphics card driver that supports OpenGL2 or later.

As stated above, randomness in human reaction is much more closely described by brownian noise than by purely random numbers (white noise). Brownian noise has a touch of "memory", that is, the next deviation is influenced by the previous one, and even from several earlier deviations. I think that a first order solution can be completely deterministic, but under the control of a user in possession of a trained musical taste. A further approximation could be attained adding some brownian noise.

Technical note: Brownian noise is the integration of white noise, a mathematical operation that enhances low frequency variations. Using brownian noise works better because phase is also the integration of instntaneous frequency. Tempo is sort of a frequency (the frequency of beat events, or of MIDI ticks), and the timing of such events is equivalent to phase. Human control is predictive through internal clock, so what one controls is the rate of future avents, which is equivalent to tempo. That's why controlling tempo is so much effective than controlling timing.

In a large group there are other effects which could be considered, such as the reaction time to indications of the coductor, which has individual variability, and the distinct delay due to sound propagation, which causes differences in the arrival time of sound to the conductor, which can vary from 10 ms to 30 ms or more. The sound arrival is the only feedback the conductor has to influence the next indications which in turn will influence the next notes the players will play. This effect is deterministic, since it depends on the (fixed) distance of each player both to the director and to a particular listener in the audience. Modern miking and mixing techniques allow to compensate these delays in a recording, generating a far more accurate sound than experienced in a live performance. But I believe we don't need to worry about these phenomena, since the conscious perception of music is, once more, concerned with tempo and not with timing. A timing error is quite perceivable because of the unexpected tempo change to which it is equivalent, not because the time error in itself.