The fading becomes an issue once the loop plays back the loop for the first time at the track loop seam. What we have changed is both the processing power (now the tested version of Aeros is using 45 frames of buffer amounting to 2.5ms of DAC latency, it is 30 frames on live version).
This also saves the file incorrectly meaning taking the file out of SD will have audible pop. The solution has been adding the frames and also recording 12ms (I believe) more at each loop’s end to add to the tail of the recording and create a seamless crossfade. I have heard it and it is now seamless.
This is due to RPO on press not being fine tuned, I believe, we can see how this feels with 3.1.x release. Please let us know if you still have this issue later. One solution to your problem is this, see the freeform song to Sync length, record the first track, if you notice timing was off slightly off but still somehow in time, with itself, you can offset the starting point of the part by recording a second part at the correct relative starting point, and making it longer (preferably 2x) than track 1. End of Loop and sync start rules all follow the longest current track in song part.
No, this is not possible, importing to the Aeros is something we hope to tackle soon. For now, we hope to improve the standalone behavior to not need to do that in the first place.
As a general reply to OP request, this is most likely not going to be done, it will be tagged ‘considered’. A function that may override the need for this is a punch i/o feature, but that is advanced and a separate request.