Presently, these include

• Garbage Collection (GC pauses are unacceptable, it encourages sloppy use of memory)
• i++ (what about i = i++? it encourages hacky code, i += 1 is good enough for anybody)
• Object-Oriented Programming (it's too easily abused to make codebases that are impossible to understand)
• Exceptions (they're expensive to support, they allow hidden control flow, they make code hard to audit)
• Operator Overloading (they allow hidden control flow)
• Threading (deadlocks are hard to avoid and troubleshoot)
• Mutation (it makes code harder to reason about)

All a language has to do to be cool these days is say "we forbid [zeitgeist problem] entirely". The language does not also have to say "we've adequately replaced the functionality you might've wanted from it", nor "our replacement doesn't have new or worse problems". So there's much innovation in the direction of replacing well-understood problems with poorly-understood and surprising problems.

are there programmer zeitgeist solutions?

Presently, these include

• returning a 'result' sumtype from fallible functions
• async/await

are these real problems and real solutions?

Sure. There's always something to a fad. The errors are generally of degree, overreaction, and field of view, rather than truth or falsehood. If you have an allergy to GC, try reading https://bitbashing.io/gc-for-systems-programmers.html.

(I hate async/await, though.)

what about Erlang?

Erlang predates the development of this zeitgeist but dodges most of its attacks.

• Garbage collection - Erlang has it, and has some of the associated problems (potential for sloppy memory managment, a heavier runtime), while dodging others (bugs from shared mutable memory) while having a very carefully designed GC setup to keep it a suitable language for soft realtime problems.
• Exceptions - Erlang has them, but in practice is actually similar to Rust or Go here: errors are communicated to callers non-exceptionally as a rule, and severe errors result in death: in Go/Rust, via a catachable but rarely caught panic(); in Erlang, via a catchable but rarely caught exception. But whereas programmers are still struggling with how precisely to handle errors in zeitgeist languages, Erlang has a well-developed framework for reliable systems with OTP.
• Threading - strictly speaking, you can replicate a deadlock in Erlang, but any concurrency concern with Erlang is a concern that's encountered on an Erlang node, which is much like a little operating system that you can ssh into (erl -remsh nodename) and do all kinds of reflection and troubleshooting on. The programmer experience is completely different.
• Erlang avoids mutation, OOP, operator and other overloading, and lots of subtle weirdness related to these.

Implicit in many of the zeitgeist GC complaints however is a complaint about large runtimes, and an Erlang node is a very big runtime for a little CLI application. Some communities really enjoy scoffing at 'hello world' executables, but it's less funny when a build system using a bunch of Python scripts starts to suffer from Python's already enormous overhead.

Implicit in 'threading' is a desire to take trivially parallelizable loops and make them go faster with more CPUs, with minimal effort. Even C can do this very easily with OpenMP. This sort of thing results in (naive) Rust benchmarks using seven CPUs to be 2.68x faster than (careful) Erlang benchmarks using one CPU.

what's outside the zeitgeist?

• massively scalable soft real-time systems (not just heavy optimization passes and slim runtimes)
• high availability
• concurrency (oriented programming, not just threads or efficient I/O reactors)
• distribution
• fault-tolerance (not just lots of compiler guarantees)