This can happen indeed but I think these situations come up only very, very rarely in the wild. For when they do come up, yes aptitude will do a better job than apt and then your strategy to still have unstable available to the resolver will make it able to probably find a working solution.
Note, that 500 is the default pin priority, so what you also can do is to not pin trixie at all but pin sid alone with a lower priority.
Another thing you can do to avoid pinning is to set the APT::Default-Release configuration option to trixie which in turn will give packages from trixie a pin priority of 990.
Let me please compliment you that your last post shows greater understanding of apt than I’d expect from any regular user. 
If you do not want your system to be in a mixed state, you could also build yourself a system image for testing and install from that one by running the following in the reform-system-image git:
./mkimage -d testing reform-system-imx8mp
Lastly: yes, I’d say that running testing rather than unstable is a reasonable compromise for people who would not like to use bookworm/stable (because they enjoy very new packages) but who also would not like to run into the RC bugs from unstable (remember the recent ones like ALERT! /dev/mmcblk2p2 does not exist. Dropping to a shell! - #14 by josch ).
There should only be very few problems you could run into. One of them is, that the kernel on the mntre.com repositories is built in unstable and as such it uses gcc and the C library from unstable. It will sometimes be the case that the kernel is built against package versions that are not yet in testing and in those situations you will either not be able to install the more recent kernel until gcc and glibc also transitioned to testing, or you will have to make use of a more clever resolver and pull gcc and glibc from unstable for the time being.