In my opinion, the fundamental difference between an architect and a staff/principal engineer is that architects are more generalists and principal engineers are more specialised. It does not mean, of course, that architects don't or can't have deep knowledge of specific areas or that principals can't have a wide understanding of their ecosystems, but an architect absolutely must understand the ecosystem they work in and a principal engineer absolutely must understand the specific technology stack of their choice. Understanding that every choice is a trade-off and comes at a price, that someone at some point will have to pay.

You chose the latest and greatest web framework? Great! How many developers at your company will know how to use it? How long will it take for them to learn it? How big is the talent pool you can hire from? How much time will it take to migrate your products to it? Who will support it, is it "wild west" open-source or does it come with commercial support? How does it fit with your deployment model? Has it gone through rigorous threat modelling? There are about a billion factors that may affect your choices and finding the right solution will always be a central part of the problem.

To actually answer your question about how I deal with this, this is why I do research. Let's say our product people come up with a brilliant new product idea that we don't have an existing solution for, then I'll spend some time on finding information about the available options and take notes on the benefits and drawbacks. I will try to find people who are experts in the subject and get their opinions.

What I can not do, is to actually go and gain a deep understanding of every single language/platform/framework/library there is, I'm just a human after all.