Explain the problem as you see it
Currently it is possible to define an option field where the source of the options is a search node. This is extremely useful for filtering the possible values in the option field, as opposed to say just making the field an instance type.
However, the search node does not have access to any of the other fields in the supertag to which the field belongs. This actually prevents many of the most important ways one might want to filter the options.
Why is this a problem for you?
A typical example might be a project management system. I have multiple projects. Each project has tasks associated with it, and also sprints/cycles, and the project's tasks will be variously associated with those sprints/cycles.
Currently I can use a search node to filter out past sprints/cycles, but there is no way to filter out the sprints/cycles belonging to different projects. This is especially problematic as the sprints/cycles from different projects might all be similarly named, say "Sprint 11". In this scenario it is extremely easy for a user to assign a task from one project to a sprint/cycle from a completely different project.
Suggest a solution
The search node which is the source of the options field needs to run in the context of the tag the field is part of. There should be a search operator which evaluates to the current tag instance, for the sake of the example let's say the new search operator is INSTANCE. Then it would be possible to create a search node for the options field like this:
#sprint
NOT >Status Past
>Project INSTANCE.Project