During plugin install, users should have the ability to choose whether or not the dynamic CLSID (8AD...) gets updated. Alternatively, for enterprise systems, the administrator should be able to set a parameter that specifies whether or not the dynamic CLSID will be modified during install.

For example, large enterprises may be running the majority of their applets on one particular version of the plugin, such as 1.3.1. If one of their applets requires 1.4.0, their users will be prompted to download 1.4.0 and this plugin will now become the default. However, this may cause problems for the 1.3.1 applets. Large organizations may be unable to migrate all applets to 1.4.0 easily, or even to change all of their HTML pages to specify static versioning for the 1.3.1 applets. With this new feature, they could maintain control over their internal environment, and could also recommend to their external users which plugin should be the default.

Another problem may exist when earlier versions of the plugin are downloaded on top of later versions. A user may have only 1.4.0 installed on their system. Now suppose they encounter an HTML page which specifies the static CLSID for the 1.3.1 plugin. The user will be prompted to download 1.3.1, and 1.3.1 will now be pointed to by the dynamic CLSID. If the user now goes to an HTML page which specifies the dynamic CLSID with the 1.4.0 codebase, the user will be prompted to re-download 1.4.0, even though they already have it. Perhaps, the user could be warned if an installation is going to make a version older than their current one the default and they can be given the option as to whether or not they want to do this.