There is --validatedeployrequestid or -q flag for force:mdapi:deploy
-q, --validateddeployrequestid=validateddeployrequestid request ID of the validated deployment to run a Quick Deploy
To run quick deploy of a recently validated package, use -q with the validated ID.
sfdx force:mdapi:deploy -q <validationRequestId> -w -1
The place to look is the Metadata API Developer Guide, in the Metadata Types section.
Note on terminology: these are not Custom Metadata Types. Custom Metadata Types are a specific Metadata API entity. CustomObject, for example, is a built-in Metadata API entity.
It's undocumented but it is available as enableOotbProfExtUserOpsEnable property in the communities settings metadata as of v47 (Winter '20). If you select the Allow using standard external profiles for self-registration and user creation checkbox and then retrieve the settings metadata using this package
<?xml version="1.0" encoding="UTF-8"?>
In my experience, most of destructive changes can go through post destructive. Pre destructive is only needed when you want to make changes inside your deploy and you have some reference that isn't going to allow it.
For instance, if you want to change some custom field type to another type that isn't allow you will need to delete it and all its references ...
Custom settings act like sObjects and therefore the fields Values you're talking about are just like any other record of any other Object, since on the change sets you're only deploying metadata, there's no records there, so the values of instances of Custom settings will not be populated by any deploy.
I'm not aware of such an API, or any other way of extending standard metadata like this. I think you might be forced into:
Storing the values you require as some Custom Metadata Type, with a 'Key' field that holds the Object and Field API names for querying.
Storing the values in some global utility class, with each JSON string being a value in a Map of <...
I was wondering if it's because the two orgs are in different pods. One org is in a pod in the Japan region, the other is in America's.
Pretty nearly, yeah - the org's language. The language of the org is set when it's created - if it's a scratch org, for example, it can be set as language in the org definition file, or will take the default language of its ...
In addition to identigral great answer, here is the corresponding code for scratch org creation (project-scratch-def.json)