Let me disagree here.
While there can be a valid scenario when you run both full Splunk Enterprise instance as well as the forwarder on one machine it's such an unusual (and unsupported) scenario that it's up to the admin to work out a good method of installing it that way (like one instance deployer from RPM and other from tgz). Introducing a completely unforeseen undocummented and - frankly - unwanted change into the package is a very ugly thing.
Sorry to say, but this is not something a respectable packager should do.
To make things even uglier - the "fix" introduced in RPM install scripts leaves you with two splunk-related users on your machine - one is the old one called "splunk", another is the new one called "splunkfwd". Of course if you had any permissions granted to the splunk user they won't "migrate" to the splunkfw user so simple upgrading forwarder package might actually break your installation. That's something that should never happen!
If you want to introduce changes and have stuff that is backwards-incompatible, look at Debian's packaging. While I might not love Debian nowadays for some reasons, they have always had very sound packages and package naming conventions - if upgrading package from version X.Y.Z to version X.Y+1.A introduces some irreversible changes, you just do separate lines of packages and tell the users to knowingly and intentionally migrate (see for example postgresql packages).
