Your question is slightly confusing.. What problems are you experiencing?
There should not not be any reason why two types can't share the same PROCESSOR O/P TYPE definition?
All this means is that if you have you can use the ENCOPTBL flags to prevent duplicate elements across types / systems / subsystems.
The standard we have is that the PROCESSOR O/P TYPE is always set to be the same as the output source library name. So, if type types - eg COBOL and ASM - write to SRCLIB then no two elements can have the same name across systems.
Changing the type definition.. well, as long as you have no elements registered you can do a BUILD SCL FOR TYPE PJCL ; modify the value PROCESSOR OUTPUT TYPE "PJCL" ; save the SCL ; apply the SCL with a batch job. Or, if your site is really progressive: Retrieve the Config element from your ADMN or CONF or CNTL environment ; make the config change ; add the element back in ; promote the element.
If your question is 'can this be changed in place' then I believe that the answer is no. The elements need to be transferred or deleted first.
We had a similar program with some ancient COBOL programs in PRD with the wrong (and very invalid) processor group. Our solution was: 1) Backup all libraries involved and execute element unload for affected elements ; 2) Create new COBOL processor group ; 3) Transfer the elements in place (with no output library delete behind) 4) Delete the old (invalid) processor group.
Wash, rinse, repeat for a few hundred elements in Production. Try to ignore the user's screams of agony and pain when this had to be done to ACM linked elements (Copybooks mostly).