Yes this is what i did indicate at the beginning of the post : 
So here is the description :
When recording audio over existing material, a new event is placed over the previous one. If you are rerecording a small length over a previous longer take, then the new event is smaller that the previous underlying one, and then autocrossfades are applied at the start and end of the new event, to merge audio with the existing previous take.
So yes this is an autocrossfade, or more exactly it should be because and it is actually not shown neither played like an autocrossfade but like a fade out followed by a fade in at the end of the recorded material. Please listen to the .wav example i did post in the first post. You will ear clearly that there is no autocrossfade at the end of the take. This example was done with a 500 ms autocrossfade setting, not very common, but i did choose this value to clearly show the problem. In the last post i did show a picture with a 50 ms crossfade, very common for recording, that exhibit exactly the same problem. So the problem i did describe first is not linked to the long autocrossfade length i did choose in the first test.
Autocrossfade or not, this does not change the problem : when a punch in / punch out recording is done with Nuendo (perhaps with Cubase too if they share the same record code, could someone test that ?), the end crossfade is wrong and affect the mix quality.
When we see the just upgraded 64 bits mix engine of Nuendo 8.2, giving extreme precision in audio processing, such a bug is a terrible thing compared to the global editing precision and audio quality we get with Nuendo.
And anyway, it’s a terrible thing from the start. I think that it did stay hided probably since years because Nuendo does not draw autocrossfades on events waveforms. You need to listen carefully with delicate audio material, or bounce the events, to clearly see it.
Another probable reason that explain why it did stay hided, is because tracking is not the strong point of Nuendo, so i think that most serious recording studios are using Protools for this task and it does have some clear advantages here like destructive recording or unlimited record buffers compared to Nuendo.
I would say that it must be corrected asap for the reputation of Yamaha and Nuendo, but not only. Tracking with Nuendo is not actually a good idea, seen as an audio quality perspective, as soon as there are tracking takes with punch ins / punch outs.
Protools does not exhibit this bug. Basic bugs like this one affecting audio quality must be tracked and corrected as a top priority.
I gave the solution in the previous post : a post-record buffer need to be added to give enough audio material at the punch out, and the code corrected to apply an autocrossfade on punch outs instead of a wrong fade out followed by a fade in.