To be sure, it's not the package that is causing this malady, but specifically a defect in the installer itself as published by Oracle. Hopefully it's an isolated defect in this release and will not appear (or will be fixed) in future releases.
Generally speaking, these different patch versions will likely coexist. The JRE6 update 7 was intentionally left behind (ostensibly for compatibility reasons), and many systems went through continuous updates to the JRE6, and even on to JRE7 before patch admins recognized the need to manually uninstall the ancient JRE6u7 package.
In the meantime, there are a few different ways you can deal with this malady.
The first is to just deploy the package, and then deal with cleaning up the JRE8u25 as a secondary task. You can build a Software Uninstallation task using Patch Manager's Computer Explorer -> Installed Software tab, and that task can be targeted to all of the JRE8u25 systems.
The second is to customize the JRE8u31 package to explicitly remove the JRE8u25 update. Whether you do this before or after actually installing JRE8u31 is a matter for additional discussion. If you uninstall JRE8u25 before installing JRE8u31, and the installation of JRE8u31 fails, then the system may be left with no JRE at all. (Some would say that's actually a better state than with any JRE installed.) Uninstalling JRE8u25 after installing JRE8u31, as with the previous suggestion of doing it completely separately, does presume that the two installations are completely isolated, and that removing JRE8u25 will not negatively impact JRE8u31 in any way.
Another option would be to code the uninstallation via Group Policy and do it as a system startup event.
Or just script it with a list of machine names.
Regardless of which methodology you choose, testing in controlled conditions prior to unleashing on the organization as a whole are strongly encouraged.