This is wrong because Inactive service should always be created. The common use case needs always an inactive service:

1) Add a module containing rar
2) Add a resource-adapter and activate it. It will create INACTIVE_RESOURCE_ADAPTER_SERVICE and  RESOURCE_ADAPTER_DEPLOYER_SERVICE. First one containing only metadata from rar (module) itself, while the second one start the runtime service ResourceAdapterService merging those metadatas to ones provided in resource-adapter
3) Add and activate another one resource-adapter using the same module. It will not deploy module rar (there are check above this change to avoid this and so RESOURCE_ADAPTER_DEPLOYER_SERVICE...even if we could have a bug on INACTIVE_RESOURCE_ADAPTER_SERVICE in this case), and when you activate it will use inactive-rar service metadatas, merge its own and start the runtime ResourceAdapterService
4) User change config on an already defined resource-adapter and call :activate again on this. The runtime ResourceAdapterService is stopped (and service removed) and use inactive-rar service merging its own new metadata and starting runtime ResourceAdapterService

Moreover you are saying that the root cause of the problem is that in some case resource-adapter is already activated before explicit call to :active. It would possible only if ResourceAdapterDeploymentService.AS7RaDeployer#checkActivation return true, and it's possible from module because ironjacamar.xml is not considered (internal file forcing activation of a rar) and there is an explicit check there about pure inflow rar to don't activate automatically it if they come from module w/o

Feel free to ping me on IRC to discuss the issue and finding a solution