Better way to refactoring stacks (renaming logical ID, stack name?)

I'm sorry but I couldn't find a better place to write this.
I found that refactoring CF stacks is hard. It would be much easier if I can rename logical ID, and stack names.

CDK promised us 'you can build your own abstraction', and it means we need to refactor them. But I can't. I can't move CDK constructs around or even rename them in-place since it'll delete existing resources and recreate it.

There is a manual for refactoring a stack (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/refactor-stacks.html) (it is not easy to remove/replace references to resources to be deleted: https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/683), but not all resources support import as the manual says, and the operation is not atomic even if luckly all of them supports it. (being able to import a resource into multiple stacks would provide atomicity?)
e.g. `@aws-cdk/aws-eks`'s Cluster relies on ```AWS::CloudFormation::CustomResource```. It doesn't support import.
`AWS::EC2::InternetGateway` supports it! However, `AWS::EC2::VPCGatewayAttachment` doesn't. `@aws-cdk/aws-eks` uses `AWS::CloudFormation::CustomResource` for creating, managing EKS Cluster (as a workaround of this limitations? https://github.com/aws/aws-cdk/issues/11403), but it doesn't support it too.

I feel like I have limited choices:
1. Refactor them anyway by sacrificing downtimes, or risking data losses by mistakes.
2. Bear with old names. It means have to digging abstraction layers, and add a ton of `this.renameLogicalId('PublicRouteTableIGWFF92FCC4', 'SmallMistakesOfThePastIGWABCD2134')`. (I currently chose this. I hope that someone who will maintain the code is not psychopath who knows where I live)
3. Don't use CDK, and don't be tempted to refactor them. No one tries to refactor CF stacks.
4. Apply `DeletionPolicy: Retain` on all resources and abandon CF.

I wish there is a better way to refactoring stacks.