Context Navigation

Changes between Version 1 and Version 2 of Ticket #34871, comment 10

v1	v2
7	7	I think this has some ties into #24267 where the idea would be that we'd introduce an `UnresolvedLookup(BaseExpression)` class initialized from `__init__(self, field, **lookup)` and that would store `F(field)` in its source expressions and thus allow `replace_expressions` to take place normally as `Q` would be storing `UnresolvedLookup(key_parts[0], key_parts[1:])` instead of tuple of the form `tuple[str, Any]` as children.
8	8
9		All `UnresolvedLookup` would do in its `resolve_expressions` is ~~what can be found in the trailing part~~ of `Query.build_filter` today that calls `solve_lookup_type`, `resolve_lookup_value`, and `build_lookup` but it would behave like a normal expression and avoids all the hacks we have in place today that special case `Q` objects.
	9	All `UnresolvedLookup` would do in its `resolve_expressions` is [https://github.com/django/django/blob/f835787f714cf000603516188b5516f87aa348b1/django/db/models/sql/query.py#L1496-L1598 what can be found in the trailing part] of `Query.build_filter` today that calls `solve_lookup_type`, `resolve_lookup_value`, and `build_lookup` but it would behave like a normal expression and avoids all the hacks we have in place today that special case `Q` objects.
10	10
11	11	Until work towards ^^ can be made the best solution here is to use lookups directly