UXP Premiere Pro — How to slip-edit a VideoClipTrackItem? Razor/blade equivalent?

I'm building a UXP hybrid panel for audio-driven multi-cam editing in Premiere Pro 26.2.2. The core operation should be conceptually simple: blade each camera-track's nested-sequence clip at every cut boundary, then enable/disable each resulting segment based on which camera is active.

The Premiere UI razor tool does this trivially — each resulting piece keeps the correct source mapping (left = source [0, T], right = source [T, end]). I have not been able to achieve the same result through the UXP API, and a community manager confirmed 7 months ago that "There is not yet any UXP API that mimics the razor tool."

I've now exhausted every documented and reasonably-undocumented composition I can find. Posting in case (a) something has shipped recently, (b) I've missed a method, or (c) one of these is a known bug that needs reporting.

Approaches tried, with observed behavior

1. createCloneTrackItemAction (overwrite mode) + createSetInPointAction — setInPoint has two distinct behaviors:

   • In-point ≤ current source out → "trim head" (shifts seq start by the in-point delta)
   • In-point > current source out → extends source (true slip, no seq shift)

   Whether a clone hits the first or second path is determined by cut spacing. For a 60-cut sequence, ~59 segments slip correctly. The one segment whose target in-point falls within its current source out is irreversibly seq-shifted, leaving a visible gap in the timeline. The rule is roughly 2 × cut[i].startTimeSec < cut[i+1].startTimeSec triggers the bad path.

2. createSetStartAction(originalStart) after the seq-shifted setInPoint — no observed effect on the trackItem's sequence start.

3. createMoveAction(shiftAmount) — docs: "moves the inPoint of the track item to a new time, by shifting it by a number of seconds." Actual behavior is a slide (moves the entire clip on the timeline), not a slip.

4. createOverwriteItemAction with Sequence.createSetInPointAction / createSetOutPointAction set on the source nested-sequence's projectItem before each overwrite, all in one transaction — marks are ignored. 60 cut spans produce 67 segments with sub-divisions that don't align to any cut boundary.

5. createInsertProjectItemAction (limitShift=true) with the same marks — marks are partially ignored. Inserts land ~2.5s offset from the requested time with the wrong duration. limitShift=true does not actually prevent ripple in the multi-track case: V1's fill placed on a new scratch audio track, V2's fill onto the same now-existing track caused all of V2's subsequent video content to shift forward by the fill duration.

6. setOutPoint(TINY) → setInPoint(target) → setOutPoint(target_end) on a single segment to force setInPoint into the extend path. The docs for createSetOutPointAction say the parameter is the out point "relative to the start time of the project item referenced by this track item" (absolute source coord). Actual behavior treats the value as added to the trackItem's sequence start — setOutPoint(162.60) on a segment at seq [150.58, …] produces seq end 301.22, not source out 162.60. This looks like a docs-vs-implementation bug worth reporting separately.

Questions

1. Is there an action factory for a true slip edit (change source in/out without changing sequence position) on VideoClipTrackItem / AudioClipTrackItem that I've missed? Or has one been added in a recent Premiere release?

2. If not, what is the documented composition of existing primitives that takes a clone at seq [S, S+T] with inherited source [0, T] and produces seq [S, S+T] with source [S, S+T]?

3. Is there a documented path to invoke ExtendScript or QE DOM from a UXP panel in Premiere Pro 26 (analogous to Photoshop UXP's host.evalScript)? If razor only exists in QE DOM, that's currently the only path I'm aware of for getting this operation done correctly, but every existing plugin doing it appears to be a CEP plugin — not a UXP panel with a CEP bridge.

4. Is the createSetOutPointAction absolute-vs-delta behavior described in #6 above a known bug? Should I file it as a bug report?

Environment

• Premiere Pro 26.2.2
• Windows 11
• manifestVersion 6
• uxp-hybrid-plugin-sdk-main (current)
• C++ native addon for audio analysis (RMS sliding-window over WAV/MP3/MP4)

Thanks for any direction. Even a "we're adding slip support in 26.x" would let me wait rather than rewriting as CEP+ExtendScript.