My solution to this problem is relatively simple in comparison to some of the other posts. First you don't need to be on the latest tech stack. Tech stacks come and go, but some stick around with force for a very long time. In fact the most successful will always stick around. For instance, while I wouldn't start a new Java based stack today, I would have no problem starting a Kotlin one, which will end up using the same technology under the hood. The reason is that I'm not particularly found of Java, but I'm pretty sure there are a huge amount of people that would start a brand new Java project with no hesitation. And they would be right to do so. Consider the following:
- what is your team familiar with?
--if your team is comfortable with a strong, battle tested technology, that's a strong incentive to use it.
- is the technology of choice not too obsolete?
--if you start a brand new Cobalt project, then you are dealing with some serious problems in your environment. In fact, in some extreme cases, choice is non-existent, but in those cases you would not have the so called "decision fatigue" to begin with, since there would be no choices to speak of.
- does stack X solve a problem you are having with stack Y?
-- if the proposed stack doesn't address real world issues with you current stack, than there is no need to change.
- is stack X an evolution of stack Y?
-- in same cases the new stack is very familiar, an evolution of kinds of your current stack. For instance .Net Core is and evolution to regular .Net. In those cases, migrating your team to the new stack should be pretty easy and provide some benefits. Just be careful not to jump the ship too early. Make sure the features you rely on are available, and that the new platform is stable.

If you read the above, you might get the impression that I'm saying people rarely change stacks. And that's actually true. At the end of the day, people tend to stick with what they know, because it works, and has worked for years. Rewriting software is risky and expensive. But even for new projects, if the teams sticks to their current tech stack, they can reuse years of work, as well as rely on the expertise they acquired through the problems they faced. Now I know that this kind of question often comes from people that are either new to the field or not very experienced. So I will give some advice if you get a fresh start, as in a start up with no legacy code or existing team, or if you are building or own project, or maybe you get a team that is somehow isolated from the rest of the company.

Basically if you have no real world bias (as opposed to personal bias) towards any tech stack, then the only solution is to do a lot of research. Building prototypes often help test out the options. But first learn about them. Learn their motivation. Why was this stack built to begin with, what problems were they trying to solve. Are their problems similar to what you expect in you project?

Sometime people build new stacks to address real world problems. Some times they build them because they can. I'm not saying you shouldn't use a technology just because the other had no good reason to built it, just had to opportunity. Sometimes people build really good products even if they are not trying to solve world hunger. And if you find such stack go ahead. But in general, try to find stable, battle tested tech, that solves your particular problem. Ignore the trends, focus on reliability and familiarity.