You don't state what the use case is you're trying to achieve, so I'm making some assumptions in my response.
Disclaimer I suggest that you use this discussion as a guide. You need to develop, test, and document procedures for your own use cases so that you can support your deployment. If you run into questions, post them back to the community. We're here to help but we're not experts on what you are trying to do..
This isn't an official answer, but here's how I'd answer your questions.
> Does a complete copy of a fully powered-off VM’s directory allow that VM to be restored while preserving its identity:
Assuming that the VM is stored in its entirety (virtual disk, configuration, etc.) in a single folder, then backing up that folder while the VM is powered off will preserve the entire state of the VM at the time it was powered off. That includes any BIOS-related UUIDs, snapshots, virtual network configuration, TPM configuration and TPM contents.
This applies to VMs that you move to the same host or to another host.
> Is the VMware encryption password, together with the complete copy of the VM directory, sufficient to restore and open the VM?
Yes.
> Must any additional files, metadata, or elements outside the VM directory be retained?
In most cases, no.
If you are using linked clones or have configured virtual disk files to residing outside the virtual machine's folder, then you have to make sure that those folders are included in your backup. These are not common configurations, though.
Also, if you have a custom virtual networking configuration that you're using in your VM (outside of the default host-only, NAT and bridged networks) you must ensure that that the same virtual networking configuration exists in the VMware Workstation environment that you're moving the VM to. Or you'll need to change the VM to reflect the virtual networking that's available on the system you're moving the VM to.
> Is there any dependency on Windows Credential Manager, the user profile, or the source host?
Again, no.
As long as the user has read/write permissions to the restored virtual machine's folder and all files contained in it, then the user should be able to power on the VM.
There's no dependency on the Credential Manager. Workstation uses it as a convenience to store the VM's password so that you don't have to type it in every time you power on the VM. But use of the Credential Manager does not relieve you of the responsibility to remember the VM's password. There are operations that will require you to know the password as it won't be used to automatically unlock the VM -- such as moving it to another user or system. A new user of a restored VM would have to provide the VM's password at first power-on and then could opt to save it in the Credential Manager.
A Workstation VM sees the hardware CPU type that the host is running on. If your application or operating system is sensitive to the capabilities of the underlying CPU (e.g if the guest operating system expects a hardware instruction that doesn't exist on the host that you're trying to run it on) then there will be an issue -- and there's nothing you can do about that.
Additionally, the virtual hardware version of a virtual machine must be less than or equal to the maximum virtual hardware version that is suppored by the VMware Workstation that you are going to be running. For example, a virtual machine configured with virtual hardware version 20 created on VMware Workstation 17.0 will power on under VMware Workstation 26H1 since it supports virtual hardware versions up to version 22. But a virtual machine with virtual hardware version 22 created on VMware Workstation 26H1 will not power on under VMware Workstation 17.0 as it only supports virtual hardware versions up to version 20.
> Please specify the applicable conditions and the correct choice when Workstation asks whether the VM was moved or copied.
Moving a VM's folder to another folder, copying a VM to another folder on the same machine, or restoring it to another system would all trigger the "moved or copied" message.
If you want to preserve the virtual machine's identity (and that includes the BIOS UUID and virtual network adapter's MAC address) then you should answer the "moved or copied" question as "I moved it". Answering "I copied it" will change aspect of the virtual machine that could be considered as changing its "identity" -- in particular the BIOS UUID and the virtual network adapter MAC address. This isn't usually an issue with Linux virtual machines, but could have an impact on Windows virtual machines. These types of changes can make Windows think that it is running on another system.
Claude AI indicates that changing the BIOS UUID or MAC addresses won't directly impact the TPM but there may be interactions with other things. One such interaction is if you have Bitlocker enabled in a Windows VM - Claude indicates that there may be some interactions that might require Bitlocker recovery. In either case, I believe that the TPM contents are not altered.
Side note, clones of a Windows virtual machine simultaneously running (either on the same machine or on multiple machines) is a violation of Microsoft licensing. Each copy of Windows that is running needs to have its own license to be properly licensed. Which would also imply that they should have their own "identity".
If your intent is to distribute a clone of an existing Windows VM to multiple machines and have them run simultaneously you should investigate the use of Microsoft sysprep so that each individual virtual machine can get its own identity and be licensed properly.
> For a partially encrypted VM, does this restoration preserve exactly the same vTPM, including its cryptographic identity and persistent state, rather than creating a new virtual TPM?
Yes.
> What procedure does Broadcom recommend for restoring this VM without recreating, replacing, removing, or resetting its vTPM, and without losing its cryptographic state?
Just restore the VM's folder.
When powering on the VM, I recommend:
- If you get asked if you "copied or moved" the VM, answer "I moved it".
- If you get asked to upgrade the virtual hardware, opt NOT to upgrade virtual hardware.