Hah, I am aware of that - I’m using Shuriken since it was introduced in 3.5 
I guess it’s not easy to fix something that you just inherited in a state like this 
But long term, are you planning to keep the system as is? I mean, there are never good moments for fixing stuff like this but maybe it would be worth announcing that, let’s just say, in 2018.4 uv coords will be mapped in a new way? Or are you planning to rule out Shuriken and bring something new to the table (in this case it would make sense to keep these bugs for consistency reasons).
But going back to velocity stretch. I’m using ancient Unity version atm (5.6) so some things might have changed but I think the whole “stretched particles” workflow should be revamped.
I’ll start with pivot offset. It seems that it currently works in absolute world space units instead of being relative to billboards size. In almost all cases I want my pivot point for stretched particles to be either in the middle or and the end. What currently happens is that when I’m setting pivot on Y axis to 1 I am getting good results with certain speed and size of particles but as soon as I’m changing either of these parameters I have to readjust Y Axis pivot again and again. It would be much easier to have these values relative to X/Y particle size so 0.8 offset on Y would mean “offset pivot on Y by 80% of particle’s Y size” or something in these lines.
I also would love to have control of the stretch value over particle age. It really is impossible to create realistic looking sparks without reducing the stretch value over particle age. If you will look at some real-life references sparks tend to be very fast when they are created and they slow down rapidly. Due to their brightness and speed our brains tend to process that as long, thin lines. As soon as they slow down a bit they shrink back to dots. Same happens when sparks are captured on camera with normal/long shutter speeds. Sure, I can use drag to slow particles down and get somewhat similar results but I’ve been there, done that and it’s not enough to achieve this sort of result. Also, there are many cases where I actually want to keep the same velocity and just reduce the stretch.
The more I think about it the more it makes sense for me to split out the whole functionality into a separate “Velocity Stretch” module, especially if you ever plan to add similar functionality for mesh particles. I think with this approach it would be much easier to understand too. Currently there’s a dropdown list called Render Mode which is not really affecting how particles are rendered but rather of which particle type they are and how they are facing the camera at the same time. You can also set the Render Mode to “None” which only controls how main particle is rendered but it would still render trails and ribbons. It feels like too many generic functionalities were crammed into one.
