Right now a common use pattern is to have an "EmployeeName to EmployeeID" value list. Normalized systems are likely to have record in some other table, such as Tasks, which are related to the Employee record by primary key. The Pop-up menu element allows the convenient conversion of Name to ID and back.
It's also common, as a solution grows, to desire a narrowed list of "Active Employees", where new Task records can only be linked to one of the currently active employees.
In order to preserve display of older tasks, extra components are required (usually dual value lists combined with stacked elements) to accomplish a "display lookup for all employees" and "narrowed lookup for data entry".
If the "filtered portal" mindset could be applied to value lists, then we could leave the core definition of a value lists down in schema, while brining new task-specific functionality to the layout. It could reduce the number of value lists needed in a solution and lead to smarter interfaces, where the code relevant to the UI is right in the layout. Maybe the option in an inspector or modal reads something like, 'Pop-up allows user to select value where: EmployeeStatus="Active"'. The same value list could be reused in another part of the system w/ EmployeeDepartment="Engineering".
I'll admit it's a stretch, but maybe WAN caching could be further enhanced when using a single non-conditional value list. I do realize grappling calculation context between the layout and the value list could be tricky, and I don't have an answer for that.
I expect this idea may overlap in part or completely with @Filtering_Value_Lists idea (link not working). I'm hoping this use case will help to drive home the potential benefit.