I think that would be a matter of perspective. I'll think you'll find that in many cases, upgrading a product of any kind where the installation state has been changed would probably give similar behaviour. For example, if you changed a .config file for a .NET product installed via MSI, you could reasonably expect that upgrading the product (and therefore installing a new set of files) would adjust to the changed file to a known state. The key point is differentiating between product configuration and install state.
Certainly, I agree that in your case this would be annoying as it is an extra step required for you when you install an upgrade. And for that reason, I can see the value in changing how this works.
Now, the situation I need to face is that the changes required to make the installer work in the way you are intending would increase the complexity of the grid node installation - such to the point where there would be an increased risk of failed installations or things going wrong. Failed installations are the bane of any developers existence, as installation success can be very environment specific and the edge cases are not always easy to test in advance. Thus a more complex install process introduces a greater risk of frustration for many users.
As such, I'd prefer not to change the service installation step for this installer unless there is evidence that a good number of people are impacted by needing to set the service to run as a local user. You're welcome to create a request for this on the
uservoice page if you like.
