I think we can have a reasonable generic implementation for anything edge-based without too much involvement, by pulling up $data = queryfx_all(...) section, forcing a common alias to the "main" table in all *Query classes, and leaving the form field as it is right now (ie, copy/paste anywhere we want it - just like all other form fields).
Have the base Query class implement withProjectPHID() in the same way as we do now everywhere, and just not called it when not applicable.

I can see the SearchEngine using some love as well, but maybe that's a separate topic?

I understand the value of figuring out a clean extensible solution for this. In fact, I kept thinking that this should be handled automatically.

But still, is there a chance of this getting merged right now in this current state? I ask this because this is one of the last features that we need to get our designer to stop using Basecamp and give Pholio a chance.

Think about it! One less person using Basecamp!!!

+1 for merging right now this as temp feature

I'm a little annoyed by the response this patch has gotten. It's a very tiny and safe change which doesn't really negatively affect anyone, has approval from at-least one community member and will make a big impact for our team - where our designer has to work with several projects.

I'm now left with 2 options:

1. Make a patch and pull it to production and risk getting a merge conflict on our production server.
2. Wait for the main developers to do it Right™, and then use the features.

I understand the value of doing it in a clear and consistent manner. But it would be nice to have this merge since it makes zero impact on your plan, and makes a big impact for us.

I know it's frustrating when you have a small patch that seems to just make things better, but adopting these patches piecemeal slows us down overall because we have to maintain them and, in cases like this, safely undo them in a backward-compatible way when replacing them with a more general mechanism.

zero impact on your plan

This isn't true. For example, the SavedQuery storage will likely end up namespaced in the more general version of this patch, so adopting this now might mean we would need to perform a data migration when we generalize. This is much more complex and risky than just building the feature without a data migration. The number of people who can safely do a data migration patch without help is also smaller than the number of people who can safely do a generalization patch, so it may push the timeline for the real fix out.

Even if we don't end up namespacing and this patch wouldn't slow anything down very much, it is true on the balance for patches like this one. We had a more lax policy (but still fairly strict) policy on accepting patches earlier in the lifecycle of the project and pulled in a bunch of stuff that cost us later. Some contributed patches (like LDAP import) are still completely broken messes today that we haven't had time to fix. In many cases, we can't be certain how harmful a patch is until later. Generally, we've raised the bar on patches until we feel like we're accepting a very low number of patches that cost us later on.

Phabricator moves pretty quickly, especially given how small the core team is. A big part of that is being aggressive about avoiding and reducing technical debt. This patch -- and patches like it -- add technical debt by solving a problem with a planned long-term solution in a short-term way.

The benefit you get from us saying "no" here is that the project as a whole moves faster.