Yes, your concern is valid.
For a critical Power Pages application, I would avoid depending too heavily on Microsoft-generated CSS class names or DOM structure for business-critical behavior. Microsoft can update the underlying Power Pages rendering/framework, and internal classes/IDs can change over time. It may not happen often, but it is not a safe long-term contract.
A few best practices I would suggest:
Prefer supported customization points
Use Power Pages configuration, form metadata, Liquid templates, custom page sections, and your own HTML/CSS/JS wherever possible. If you must target an out-of-the-box element, try to target the most stable parent/container possible, or add your own wrapper/custom element around the behavior.
Avoid using internal class names as the only selector
If you are selecting something like .some-generated-class, that is risky. A more reliable approach is to scope your selector under a known form/page/container and use attributes that are less likely to change, for example field name, input name, aria-label, or your own custom container.
Add defensive JavaScript
Your code should fail gracefully if the element is not found. For example, log a warning, do not block the upload, and avoid throwing errors that could break the page.
Keep this logic in Dev/Test/Prod through ALM
Store your JavaScript/CSS as Web Files or part of the Power Pages site configuration and move it through solutions/pipelines. Test the behavior in Dev/Test before Production.
On your second question: you can control some release behavior at the tenant/environment level through the Power Platform admin center, but you cannot fully guarantee that every underlying Power Pages platform change will hit Test first and Prod later exactly the way a custom app deployment would. Release waves can be enabled/managed, but service updates and platform fixes are still Microsoft-managed.
So the best practical approach is:
Dev/Test/Prod environments
Power Pages site in each environment
ALM/pipeline promotion for your custom JS/CSS
Regression testing after release wave updates
Avoid dependency on internal DOM/classes as much as possible
Monitoring/application insights if this is a critical portal
In short: what you built may work, but I would treat it as a fragile customization if it depends on Microsoft-generated class names. For production-critical behavior, try to move as much as possible into supported Power Pages customization areas or your own custom markup, and keep a regression test plan for every platform update.
