It’s true that it was a little tongue in cheek.
The thing is, we cannot know if this is something that fell through the cracks during development, if it’s just us users that make a logical connection between two independent (from the programmer’s view) features and expect them to synergize, or what else. Meaningless play on words, exactly as you said.
We just need to turn the spotlight to the matter and hear back an “ok, we see it”.
@Louis_R, it was a good catch! 
@steve @ggmanestraki Thanks for you answers, let’s hope Steinberg see this. 
I lost my temper once again, although I’m trying my best to hold it in, sometimes I just can’t help it, please @st10ss accept my apologies for this. Maybe I should not have made such a long post in first place, after reading it again I really gave too much information in one go and it can confuse those who want to help. From now on I’ll try to keep it short, Socratic style 
Also @steve , are you taking part in the beta and able to communicate directly with the developers ? Oops maybe I’m not supposed to ask this here. I’ll take my chances and see if they accept.
This is a false assumption. The event doesn’t move. It stays where it was on the timeline.
And there is no difference if the start or the snap-point is taken.
Tempo information is not relevant to the time position.
I don’t get confused on that…
Ok, I was searching for the right words, because it’s hard to describe what is happening if you change the tempo.
All tracks with linear time base will stay on their position in time, no matter what measure is selected.
The events with musical time base will indeed change their time position, but stay on the bars or beats.
If you need the events to follow the tempo change, you must switch them to musical time base (tempo) before you change the tempo.
There are no apologies required, but accepted.
I had the same problem years ago and learned it the hard way.
I destroyed a project and had to re-record some performances.
Indeed, since I do mostly live recordings or other things not related to musical information, I use the “Time Linear” mode on many projects.
But this affects only what the event display is showing and how it changes as the tempo changes.
It doesn’t alter what is happening in reality.
Why are you saying this is a false assumption ? I have literally captured the behavior in a GIF :
It stays where it is on the Bars and Beats grid, since I have set the track to Musical Time Base.
It starts at the same place but its length in Bars is completely different since I have changed the tempo.
And the problem is that the anchor point is the Event Start, and not the Snap Point, so the transient I want to start on a specific Bar/Beat will get shifted and I’ll have to snap it to the grid again manually. That’s an unnecessary move. The anchor point should be the Snap Point.
So yes, there is indeed an obvious difference.
But it seems it does really confuse you.
What do you mean exactly by “their position in time” ? The position in time base can be based on multiple things, it can be seconds, bars, samples, video frames, light-years, etc. That’s why it is called “Time Base”.
You keep writing this with “Seconds” in mind, which makes your own posts very confusing to read.
Once again, when changing the project tempo :
Linear time base keeps the Events on the Seconds grid position.
Musical time base keeps the Events on the Bars+Beats grid position.
In Cubase and Nuendo this only means the number of seconds or samples from the project start to the event start location.
Anyways, what we are talking about has nothing to do with the issue.
The issue is about the reference position of audio events (Snap Point). Period.
In that case, please continue in one of your other threads about the audio Snap Point.