Implied Pairs in the Vibration API

I really don't like that the Vibration API assigns meaning to the numbers
in lists handed to it based solely on the oddness of their indices. This
means developers have to be incredibly careful to only ever extend their
lists two items at a time or risk subtle, difficult-to-track-down bugs.

One solution would be to create lists of lists of [activeTime, restTime],
but even this creates a situation where future extensions of the API would
have to run on top of a completely different interface.

>From my perspective, the *right* way to do this, while a little more
verbose, would be much more extensible and much more explicit; have the
thing take a list of vibration objects formatted something like {time:
[number], vibrate: [bool]}. This means you don't have to keep track of the
index of every item you append to your list and you open the door to future
parameters such as intensity or, who knows, motor selection in hypothetical
multi-vibration-motor devices.

It would, of course, be possible to support all three of these interfaces,
if so desired.