Sorry, what happened should be:

When align:middle is set and position is 60%, the caption appears left of where the 50% position is.
When align:start is set, the positions under 30% appear to be scaled in to a curve. 

Confirmed. Seems to be related to using line percentages. For instance, with the original testvtt_position.vtt modified to use numeric lines (not percentages) for align:start, then no curve was observed. (modified vtt attached).

Deleted: mod-alignstart.vtt 781 bytes

mod-alignstart.vtt 781 bytes Download

Note, one alternative "working" page we had looked at (from johnpallet@): http://ronallo.com/demos/webvtt-cue-settings/ does *not* set the line position as a percentage. If you simulate that by entering the following into devtools console when that page is loaded:

document.querySelector('video').textTracks[0].cues[0].snapToLines = false;

and then slide the "cue settings position" slider on the page left and right, you'll see some interesting behavior. Further, continue switching snapToLines true and false and sliding that position appears to incrementally corrupt the position.

It appears that something in the non-snapToLines positioning is incorrect, if not also snapToLines (either in spec or impl, or both). This bug tracks figuring at least that out now :)

Note, either pixel layout test(s) or unit test(s) would be good to add to verify broken, and eventually fixed VTTCue display parameter calculations in the context of !snapToLines, and also when alternating values of snapToLines.

I think this existing FIXME in LayoutVTTCue, for when !VTTCue.snapToLine, might be the root of the problem:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutVTTCue.cpp?sq=package:chromium&rcl=1475767319&l=285

I suspect what we're seeing here is https://w3c.github.io/webvtt/#apply-webvtt-cue-settings (primarily steps 2 - 5) and the interaction with 'size' (which looks like it's 100% in all these cases.)

The FIXME in LayoutVTTCue is unrelated (that would be substep 4 of the snap-to-lines=false case of step 11), the code to compute the initial positions is in VTTCue::calculateDisplayParameters.

Forgot to mention: We also have a TODO in VTTCueBox::applyCSSProperties, which is somewhat related to this. We still implement the old align behavior for non-snap-to-lines cues. I wonder if that might be what gives rise to the "curve behavior".

This issue is fixed with below patch
https://chromium-review.googlesource.com/c/chromium/src/+/753102

Resolving per c#10.