Added a patch. Tested on master, possibly works with 3.1 (where you can't put tile-dependend reqs on units but can on buildings). Possibly, in 3.2 we should remove .unttype from can_city_build_unit_direct() check in city.c since we don't have any relevant reqs here that would sanely check it.
Can't test now but looking at the code v.3.0 also does not call callbacks or show messages for inability of build a building due to Local/(C)Adjacent tile reqs. Just it needs another patch.
Might still make it to 3.0.5. I created the "3.0.6" version definition just to place there some tickets that I already know that I won't work on during 3.0.5 cycle.
Hm, in 3.0 it won't postpone a building if !can_city_build_improvement_later(), and no adjacent terrain etc. is considered a "never in million years" blocker. Likely, fixing this logic may change how scripts work (that now get "never" reason insto "need_terrain" etc.) I'm in doubt should we do it...
Digging in, is_req_unchanging() is what blocks consideration for future here (and it still blocks it in 3.1+, by the way). This function and its dependents should be probably moved somewhere into AI code since they mean "things that AI does not know how to change" but occur in some non-AI-related cases like this one.
Good findings.
For this ticket, I'm waiting your recommendations about target branches, and which are the final patches for those.
Well, since can't build reasons is a documented part that is supposed to work, we should develop patches since 3.0.x Just it is going to be more complex than just supplying a tile in one place.
3.0 pacth added, but it does few good without #46029 version.
Noticed in #45907. The result is that tile-dependent requirements are treatened as "possibly true" and the message or the signal are not shown. The city, actually, submits its tile when it builds a unit or a building.