At this point we're reaching limits of IDE support[0] and language design. New languages have been piling up increasingly arcane mathematical abstractions to try and squeeze in a lil' bit more stuff in the same number of characters, but they too can't get past the fundamental problem: there is only so much you can fit in a piece of plaintext. You can't cover every cross-cutting concern at the same time in the same piece of code, and keep all of them easy to understand and work with. That is, we are being limited by insisting on directly authoring and manipulating source code that's plaintext and a "single source of truth".
AOP solved a lot of these issues, but it was hamstrung by being deeply embedded in that "plaintext single source of truth" code workflow. It was confusing to have "spooky action at a distance" that's invisible unless you're using a properly configured IDE, but the real problem here is that we expect everything to be local in the same piece of text. If we drop that expectation - learn to work on higher-level representations of the underlying source code - then none of it is a problem anymore. AOP becomes a subset of more general techniques of authoring software systems.
--
[0] - Perhaps with exception of LLMs, which promise to be able to both write heaps of code and explain what all that code does. We can probably ride quite far in that direction, but it'll also eventually hit the same wall: no more progress until we abandon the idea of working with the plaintext source code directly.