user5875: I have to stitch various pieces of footage together, and the final result will be about 1–1.5 hour long.
Because of all the needed changes (blurring faces, inserting images and icons in certain places, synchronising the footage pieces among each other and fading them out\in with right timings etc), my project map starts to look like this. The #3 and #4 tracks are just transitions from one piece to another. In tracks #1 and #2 is how most tutorials tell to deal with blurring\changing a screen area (duplicate the track above itself and then pan\crop the duplicate).
The problem is that in multiple places the video also has to be sped up\slowed down, and when I do it, the footage length changes like a fractal curve, and all the alignments get messed up. And besides these speed changes, the whole eventual video has to be sped up again once more too (x1.5).
This looks like one of those things that I’ll be cursing myself about later, because a simple and overlooked mistake led to losing huge amounts of time\work, so I decided to just ask about it now: am I doing it wrong, and if so—what’s the more productive way of dealing with many playback speed changes in relatively big editing projects?

user2836: It isn't a perfect solution, but you can use nested sequences in order to apply your edits separately from your speed changes.  This way the speed changes impact the final video instead of just one clip.

user2365: Your screenshot does not have sufficient zoom to see how the checkpoints of Velocity envelope behave. Let me assume they are all having Transition of Hold, e.g. velocity changes abruptly, not gradually: 100% immediately to 150%, then immediately back to 100%.
Along the course of my experience with Vegas, I found velocity envelope inefficient. Instead, I find splitting Video Event into several ones more effective, and here's why.
Say, you have a video event of length 1 minute, as on Track 1. Say, you want the original timeline 0:20 till 0:30 to play at Velocity of 200%, so that it took only 5 seconds instead of 10 original.

Full scale image here
If you add a Velocity envelope as in Track 2 (200% at timecode 0:20), you would need to guess at which point to put another control point for Velocity so that playback continued at original speed.
Also, the end marker of the video indicates that the actual timeline ends at approx. 0:54 (and the rest is a repeat of the same video event from the beginning).

However, if you take another approach and split your video as displayed on Track 3 and then Ctrl+drag the end point of the middle Event, it would work smoothly. You will be sure that the third Event starts at proper timecode (in original scale).
The only thing you would need is dragging the 3rd Event backwards, as shown in Track 4.
Moreover. As soon as you Group all three Events by Ctrl+clicking them and then pressing G, you will be able to process them together. In Track 5, I have stretched all three events so the entire video played a bit slower.

Note 1. Most likely, you will need to overlap these three Events somehow. This will let the stream to be smoother, without abrupt Velocity changes.
Note 2. Of course, all above applies to multi-track Groups as well. You need not keep all Events within the same Track.

5875: <p>I have to stitch various pieces of footage together, and the final result will be about 1–1.5 hour long.</p>

<p>Because of all the needed changes (blurring faces, inserting images and icons in certain places, synchronising the footage pieces among each other and fading them out\in with right timings etc), my project map starts to look like <a href="https://i.imgur.com/Ym2vMxV.png" rel="noreferrer">this</a>. The #3 and #4 tracks are just transitions from one piece to another. In tracks #1 and #2 is how most tutorials tell to deal with blurring\changing a screen area (duplicate the track above itself and then pan\crop the duplicate).</p>

<p>The problem is that in multiple places the video also has to be sped up\slowed down, and when I do it, the footage length changes like a fractal curve, and all the alignments get messed up. And besides <em>these</em> speed changes, the whole eventual video has to be sped up again once more too (x1.5).</p>

<p>This looks like one of those things that I’ll be cursing myself about later, because a simple and overlooked mistake led to losing huge amounts of time\work, so I decided to just ask about it now: am I doing it wrong, and if so—what’s the more productive way of dealing with many playback speed changes in relatively big editing projects?</p>
 2836: <p>It isn't a perfect solution, but you can use nested sequences in order to apply your edits separately from your speed changes.  This way the speed changes impact the final video instead of just one clip.</p>
 2365: <p>Your screenshot does not have sufficient zoom to see how the checkpoints of <em>Velocity</em> envelope behave. Let me assume they are all having Transition of <em>Hold</em>, e.g. <em>velocity</em> changes abruptly, <strong>not gradually</strong>: <code>100%</code> immediately to <code>150%</code>, then immediately back to <code>100%</code>.</p>

<p>Along the course of my experience with Vegas, I found <em>velocity</em> envelope inefficient. Instead, I find splitting <em>Video Event</em> into several ones more effective, and here's why.</p>

<p>Say, you have a video event of length <code>1 minute</code>, as on Track 1. Say, you want the original timeline <code>0:20</code> till <code>0:30</code> to play at <em>Velocity</em> of <code>200%</code>, so that it took only <code>5 seconds</code> instead of <code>10</code> original.</p>

<p><img src="https://i.stack.imgur.com/PE3uF.png" alt="Vegas screenshot"><br>
Full scale image <a href="https://i.stack.imgur.com/PE3uF.png" rel="nofollow noreferrer">here</a></p>

<p>If you add a <em>Velocity</em> envelope as in Track 2 (<code>200%</code> at timecode <code>0:20</code>), you would need to <strong>guess</strong> at which point to put another control point for <em>Velocity</em> so that playback continued at original speed.</p>

<p>Also, the end marker of the video indicates that the actual timeline ends at approx. <code>0:54</code> (and the rest is a repeat of the same video event from the beginning).</p>

<hr>

<p>However, if you take another approach and <strong>split</strong> your video as displayed on Track 3 and then <kbd>Ctrl</kbd>+<kbd>drag</kbd> the end point of the middle <em>Event</em>, it would work smoothly. You will be <strong>sure</strong> that the third <em>Event</em> starts at proper timecode (in original scale).</p>

<p>The only thing you would need is dragging the 3rd <em>Event</em> backwards, as shown in Track 4.</p>

<p>Moreover. As soon as you <em>Group</em> all three <em>Events</em> by <kbd>Ctrl</kbd>+<kbd>clicking</kbd> them and then pressing <kbd>G</kbd>, you will be able to process them together. In Track 5, I have stretched all three events so the entire video played a bit slower.</p>

<hr>

<p><strong>Note 1.</strong> Most likely, you will need to overlap these three <em>Events</em> somehow. This will let the stream to be smoother, without abrupt <em>Velocity</em> changes.</p>

<p><strong>Note 2.</strong> Of course, all above applies to multi-track <em>Groups</em> as well. You need not keep all <em>Events</em> within the same <em>Track</em>.</p>
