Doc: NR 2.2.1 keyboards, staff changes

[Keith E OHara]

Friends of LilyPond,
 I am suggesting a new @knownissues for the Notation Reference 2.2.1.  The 
corresponding bug tracker issues are 1043, 439, and 36.  If issue 1043 is 
solved, the second paragraph of my suggestion will become obsolete.

 I wrote the text below based on observed behavior of LilyPond 2.12.3 and 
2.13.33 (as opposed to understanding its code).  I have been using the 
workaround for six months, including about three piano pieces where the 
work-around-able issue came up.
--
Keith OHara


keyboards.itely
at line 215, to become the last section of @node Changing staff manually

@knownissues

Beams that cross staves cannot vertically displace other notation
like normal beams do.  Vertical collision resolution is suspended for such 
beams,
and their associated stems,
so they might overlap other notation such as dynamics.

A staff change can also prevent proper collision resolution
for a beam that ends immediately before the staff change,
if that beam was created automatically.
Specify beams near staff changes manually with @code{[} and @code{]}
to restore collision resolution in these situations.