Note: The following hack is a partial work-around for handling this issue:

urgency.blocked.coefficient                 = -256.0 # blocked by other tasks
urgency.user.tag.next.coefficient           =  128.0 # +next tag
urgency.due.coefficient                     =   64.0 # overdue or near due date
urgency.uda.priority.H.coefficient          =   32.0 # high Priority
urgency.uda.priority.M.coefficient          =   16.0 # medium Priority
urgency.uda.priority.L.coefficient          =    8.0 # low Priority
urgency.active.coefficient                  =    4.0 # already started tasks
urgency.age.coefficient                     =    2.0 # coefficient for age
urgency.blocking.coefficient                =    1.0 # blocking other tasks
urgency.scheduled.coefficient               =    0.0 # scheduled tasks
urgency.annotations.coefficient             =    0.0 # has annotations
urgency.tags.coefficient                    =    0.0 # has tags
urgency.project.coefficient                 =    0.0 # assigned to any project
urgency.user.project.My Project.coefficient =    0.0 # assigned to project:"My Project"
urgency.waiting.coefficient                 =    0.0 # waiting task

Contrary to taskwarrior recommendations, this intentionally uses coefficients which dominate all terms of lower priority.

This at least guarantees that prerequisites appear before blocked tasks. The main issue is that in computing the urgency of a given prerequisite, the relative urgency of the tasks it blocks are not factored in. Suppose task A blocks task B, for example, and task B is due soon. The high urgency of task B's pending due date should be reflected in the urgency of task A. Though, no configuration changes that I am aware of can incorporate that.

The main issue is that in computing the urgency of a given prerequisite, the relative urgency of the tasks it blocks are not factored in. Suppose task A blocks task B, for example, and task B is due soon. The high urgency of task B's pending due date should be reflected in the urgency of task A. Though, no configuration changes that I am aware of can incorporate that.

Have you looked at urgency.inherit as outlined in man taskrc?

$ man taskrc
...
urgency.inherit=0
Not actually a coefficient. When enabled, blocking tasks inherit the highest urgency value found in the tasks they block. This is done recursively. It is recommended to set urgency.blocking.coefficient and urgency.blocked.coefficient to 0.0 in order for this setting to be the most useful.

Following its advice and setting both urgency.blocking.coefficient and urgency.blocked.coefficient to 0 means you will effectively not see this, because the dependency will simply inherit its most urgent child's value. You can still leave those two udas set to what you want, but I think the original contributor of the feature does not, so you might have to play around with it to get good values.

I for one am not sure I agree with the original contributor's reasoning, as without the blocking coefficient, there is no way of representing the fact that a long and involved project of high priority tasks has some urgency in and of itself that may not be accounted for by inheritance alone.

Say I have long-term project X and then project Y that is less important but that has a near due date. Now in general we should not set due dates such that they have wiggle room - if there is flexibility in a due date, it doesn't exist; due dates are for when something must be done, scheduling is for the other kind. Regardless of this, it may still very much be the case that if push comes to shove, I would want to prioritize project X, regardless of the due date of the task in project Y. I can think of many things in my life like this, sometimes external due dates just aren't that important relative to working on something more open-ended that you need to work on. (Other times, of course, they are).

Now, I could just modify the projects themselves to have a UDA - but this seems fairly ad-hoc. It's far better IMO if I can automate that; if I wanted to question everything for myself each time I wouldn't use a task tracker with modifiable heuristics, I would use some notebooks divided by project (and this for me is more intentional than the alternative - other people hate the idea of distancing themselves from the decisions).

Equally, I feel someone may disagree with my own reasoning, and prefer to do it ad-hoc - a project with lots of planned tasks may not convey any importance to them, rather just a lot of work. For me, if I were to have projects like that that I didn't necessarily intend to carry out, I would relegate them to a 'brainstorming' context or similar. I want my tasklisk for commitments and intentions.

I think the default settings should be:

urgency.inherit=1
urgency.blocking.coefficient=0
urgency.blocked.coefficient=0

This would reflect the usual meaning of "blocking" and is more user-friendly.

I am inclined to agree at this point in time.

Re. my earlier rambles, I think realistically all that stuff has to instead be managed with tags, projects, and other UDAs to modify urgency (though it is no small difficulty arriving at sane numbers). Given it wasn't relevant to the initial question, it was superfluous and unhelpful - I apologize very belatedly.

I guess the part that should be modified is only this one:

Here is a pull-request for this part