[BUG] msdyn_project silently renamed from "Plan/Plans" to "Project/Projects" in new environments

We need clarification from Microsoft on whether this is a bug or an intentional breaking change.

Overnight and without any announcement, the msdyn_project table now ships with display name Project / Projects in newly provisioned environments. Dev and UAT environments provisioned a few months ago have Plan / Plans out of the box. All environments are running the exact same PSCore version: 1.0.163.730.

The entity is as expected, marked non-renameable — read-only in the maker portal — so there is no way to align environments manually.

Solution import from an existing environment (where msdyn_project = "Plan") into a newly provisioned Production environment fails with:

0x8004023B: Entity 44286cce-2389-4532-ac04-7a18a2818e9a is not a renamable entity. Hence Entity Display Name cannot be modified

The only workaround — and why it is not acceptable

It is technically possible to manually edit customizations.xml inside the solution ZIP before importing, removing the <DisplayName> node for msdyn_project. The import will then succeed, but Production will permanently show "Project" while Dev and UAT show "Plan" — a broken inconsistency across environments.

More importantly, this is not how ALM is supposed to work. Developers should never have to manually patch solution artifacts to work around a platform-level inconsistency introduced silently by Microsoft. This is incompatible with automated CI/CD pipelines and unsustainable for any team managing multiple environments.

The question for Microsoft

Is this a bug or a planned change?

• If it is a bug: when will it be fixed, and is there a supported workaround in the meantime?
• If it is a planned change: why was it not communicated, and what is the supported migration path for teams with existing environments and solutions?

[UPDATE]: 

After 3 attempts of resetting and reprovisioning the Production environment, msdyn_project finally came up with Plan / Plans — same process, same PSCore version each time. The behavior is non-deterministic. The only workaround currently available is to keep resetting your environment until you get lucky, which is not an acceptable answer for any type of deployment.