My question frustration can be summarized by the following:
So your statement is accurate in the context of enterprise-scale dashboarding: segments are useful for simple tiles, but their value drops sharply for complex analytical DQL because they are not composable with multi-branch queries.
Certain dashboard tile visualizers force one's hand in having to craft queries that require "append", "join", and so on due to missing language support for some common capabilities. Having said that, one after some effort comes to a solid query that meets enterprise level needs. This is only then invalidated by the usage of the UI's Segment dropdown by users because the segment's definition is *only* applied to the top-most pipeline query (the first "fetch ..."). Any "sub-queries" are unaware of the segment selection and as a consequence contaminate the results. In other words, they mislead / misinform the user.
There is chatter online about "duplicating" the segment definition logic in each dashboard, which is non-viable. Segment definitions can have wide variety of definitions which themselves evolve through standard SDLC cycles. New ones are also created over time.
Is there any agnostic workaround for this? Maybe something along the lines of:
| filter matchesSegments
