Tuplets currently render only against voice 1; any tuplet authored referencing voice 2/3/4 content is silently misapplied

N/A — implementation limitation, not a notation convention (real engraving supports independent tuplets in any voice, including simultaneous different-ratio tuplets across voices on one stave).

A lesson author wanting a triplet figure in `voice2` has no mechanism to express it — the `tuplets` prop only ever reads against `v1NoteObjects` (confirmed lines 1151-1171), so referencing voice-2 note indices there would incorrectly pull from voice 1's note objects at that index instead, producing a garbled or silently-wrong bracket.

N/A (Gradus limitation) — contrast with standard multi-voice engraving practice (Gould, Behind Bars, ch. 'Tuplets') and VexFlow itself, which supports tuplets per-voice.

This rule can be decided from pitches, durations and voices — no layout required. A validator can check it before anything is drawn.