The first bit is just a warning, not an error. Of course, you could check what has changed in v9.11 that makes this not recommended anymore. Maybe they already handle it internally when you set -dPDFACompatibilityPolicy=1 and the old setting can interfere. But when the output of the validator doesn't change, it's probably just meant as you don't need to specify this anymore, we activate it ourselves.
Speaking of the validator, those look more like warnings too and not like deal breakers. In the end, only you know what your contractor expects of you. And if they don't even bother inspecting the result, this will be irrelevant. After all, the only reason PDF/A exists is for archiving reasons. It pretty much just throws out all the proprietary clutter from the PDF standard. The important thing is that fonts are embedded to always be able to display them correctly, and that it's specified how images and other media are embedded. If your contractor expects more of you, they should pay for the appropriate software.
Richard
PS: this isn't really meant for this, but you could install Scribus and try to import the PDF there. It also has a validator similar to Adobes Preflight. Maybe it can give you a more precise result. I'm not sure if it even can output PDF/A, I only know that it does PDF/X, but maybe it can even be used for better conversion to PDF/A. The last time I tried to import a large PDF into Scribus it got kinda stuck, but it has evolved since then and maybe it was a hardware limitation.