I consider this intended behavior because it’s been this way for as long as I can remember, with the caveat that my recollection could be a little off base. I’ll explain more below.
The current behavior has a kind of logic to it though, and it makes sense (to me) once you break things into discrete events and think of things in small silos of workflows too. Slice things up into smaller events, and keep automation lanes open (and select everything on all relevant tracks and lanes) and it behaves somewhat closer to what you might be expecting, with the exception of seamless tempo awareness inside automation lanes from what I recall. I ran into issues with that for sure in the past.
If I stay inside Cubase for this kind of project that relies on this workflow (see below), the workaround I have used is extreme attention to what I am selecting, and double-checking everything. This is very very tedious. Perhaps Steinberg could improve the “automation follows events” significantly though and make it much more tempo-aware and accurate in all situations, but for now, I believe this is just the way it is. I could be completely wrong though and misremembering how things were before.
One partial NEW workaround, at least with regard to volume automation, is to use event volume curves (new feature in C14, that are obviously therefore fundamentally attached to the events), things move and scale much more logically IMO. That’s one reason why C14 was such a breath of fresh air to me, specifically this new feature. I haven’t fully tested that yet with more complex tempo changes, but from a quick test, it behaves much more logically to me, IMO.
Again, I could be wrong, but just because I think Steinberg will consider this intended behavior, doesn’t mean it’s optimal behavior, and it’s certainly not MY preferred behavior. I think it’s a holdover from a long time ago TBH. BUT perhaps Steinberg would think all this is indeed a bug though, and if so, it would then break some people’s current workflows that they rely on how it currently handles things today, so Steinberg would need to offer the option for the current quasi-broken/inefficient behavior and a “new/fixed/better/optimal” behavior. Hence why I think at this point, it is therefore intended behavior, lol.
BTW when editing complex dialog or sound design projects that have a lot of automation, tempo changes, and need lots of ripple editing kinds of workflows, for example, I do NOT use Cubase/Nuendo, since the overall workflow is too slow for me for those kinds of projects, with the aforementioned potential hiccups among other things. I have done this for years now, so this is part of the reason why I say my recollection of past behavior might be off a bit. I just know I had issues like this, and I felt a lot of frustration years ago for projects that needed these kinds of workflows. So forgive me if my recollection is not 100% accurate. I just recall this is how it’s been… but to be clear, my workaround was to jump over to Reaper, which handles all that much more intuitively IMO, at least to my workflow preferences. Cubase/Nuendo are great for what they do, but the core Steinberg workflows are not ideal for all kinds of projects.
So personally, I think the way to approach this issue is to submit a feature request for an alternate workflow, then deal with that we have today as-is, and/or possibly consider branching out to using another DAW on the side that handles those workflows better for certain projects. YMMV. And again, I could be wrong about some prior behaviors and my recollection could be off, so my whole post here could be garbage or misinformation!
BUT moreover, I do think this is probably one of the things that has been slowing down the release of true drag-and-drop ripple editing for Cubase/Nuendo, since the current behavior is frankly kind of incompatible to seamlessly dragging things around a complex timeline since there’s a likelihood that the automation will get bumped out of sync IMO, among many other things. Steinberg’s track concepts are very dense with metadata and I think drag-and-drop ripple editing will be very hard to implement 100% consistently across all track types. I believe Steinberg has to really re-engineer this whole series of interrelated workflows IMO to eventually give us the seamless drag-and-drop ripple editing that some of us have been asking for. It could be a few more years before we get that, and when it comes, I will BET there will be a lot of complaints about other broken workflows!
Just my two bits. Lots of caveats with this post. Cheers!