There is an open consideration for selecting a specific block height to initiate a period where duplicate transaction mining could occur freely before implementing a permanent solution to address BIP30 concerns. This approach, however, raises concerns about the potential need to reset the testnet if the proposed BIP30 fix does not work as intended on the testnet, even though it might be effective on the mainnet.

Furthermore, the activation of consensus-valid transactions can be deferred, but a plan must be developed for activating changes invalidated by past soft forks. This plan should include creating test vectors prior to activation. The integration of testnet4 into Bitcoin Core is anticipated to occur with version 28, expected to be released in October, which provides ample time to prepare and implement these changes.

Additionally, there is a suggestion to treat some soft forks as always active without explicit declaration in the chainparams.cpp file, especially for those that are significantly old. This approach aims to simplify the process but comes with the caveat that it should not interfere with ongoing developments or the utility of the testnet itself.