the maui workloads and dotnet runtime/sdks are released by different teams and not synchronized (except, new workloads are required for a new major release of the sdk). the maui workload team is mostly concerned with the build tools and staying current with mobile o/s runtimes (supported patched versions, not necessarily the latest).
while possible, is should be rare that a .net sdk patch release broke the maui workload. if it does just roll back or wait for a maui workload update.
maui workload changes are tied more to changes in the mobile sdks. IOS and Andriod often release a security patch that has some breaking change. old code will typically run, but a new build requires changes. as the mobile O/S will typically stop signing old code until the build is updated, the code changes must be made to do a new release of you app. this may require an update to the Maui libraries and toolchain.
you should also limit your use of 3rd party libraries, because they may not have a update cadence that meets your need. we often found a mobile o/s update broke our app, but could not release an update because a 3rd party library had not been updated to support the current runtime or build tools.
the mobile O/S are very security minded and have much more frequent updates, and required application changes than desktop applications. We find that you will need an effort every 3-6 months to bring your code up-to-date with the current mobile sdk and build chains. when using cross platform tools like Maui you should expect added complexity.