Ah, right, totally forgot about these, will definitely do this! Exact placement (before or after missing media icons?) can be the subject of an intensely heated debate later 
The operators I’m talking about are bpy.ops.sequencer.select_linked() and bpy.ops.sequencer.select_linked_pick(), their implementations are restricted to VSE code.
I’m not proposing to rename any of the other “select linked” operators; they make sense as-is IMO:
- Keyframes that are part of the same F-Curve remain part of the same F-Curve even when moving them around, so it makes sense to call these “linked”
- Same for grease pencil points that are part of the same curve, UV verts part of the same island, bones part of the same chain, etc…
- Two objects with the same material/mesh data/particle system etc. mean that changing the data on one changes for all of them, so it makes sense to call these “linked”
But strips that are next to each other aren’t linked in any of these senses.
Just proposing to rename the VSE-specific operators to .select_adjacent() and select_adjacent_pick().
I think the term “parented strips” would suggest a one-way connotation when in reality moving any linked strip will move all of them (similar to linked object data). In this sense I think the GSoC “linked strips” adheres more to the concept of “linking” in a general Blender sense than the previous naming (“linked” as “strips next to each other on the same channel”).
No, but I’ll see how it looks in combination with the link icon… seems like it would help a lot in the uncommon case that you have linked strips that aren’t just on top of each other (A/V)