When scoped to a project that doesn't have any timeboxes (iterations and releases) assigned to it, it is not possible to search for any timeboxes in a filter. The use case here is that a top level project may have numerous sub-projects with timeboxes in them and when scoped to the top level project you are trying to filter for work items that have specific timeboxes.
In the past, this was possible.
The change in behavior was necessary due to the way that timeboxes were fetched previously and that the resultset in a timebox filter is limited to 50 items.
Prior to the change, the currently scoped project was not considered when querying for timeboxes to populate the filter dropdown. Because of this, it was possible to have a single timebox that was propagated across more than 50 projects and that single timebox would push all other timeboxes off the list of candidates in our backend calls. In this situation it was probable that searching for specific timeboxes was not possible because they could not be included in the 50 results.
The change was to include the currently scoped project in the backend query to eliminate results from other unrelated projects which could push relevant searches out of the result set. This has the side-effect of not showing timebox results from other projects. Because of this, it is necessary to scope to a project where the timebox does exist in order to use it in a filter.