This is impossible to confidently answer without knowing more - I would think someone on your team would be handling such DFT planning.
In cases where I've encountered module-level TAP-ctrlrs, they've only been there for the purpose of some type of BIST, such as MBIST.
And, they were not enabled until a certain TAP instruction was selected, and would then require a reset to get back out of that mode.
And, they were typically inserted into the design by a tool, such as Mentor's LogicVision.
And, they were not in series with the main TAP, but instead were MUXed in-place of it only in this mode (though the module-level TAPs were all connected in series with each other, just not with the main one).
Note the reason for having distributed controllers had to do with practical chip-distances and/or clock-domains, plus a need to divide-and-conquer the fanouts/controls due to the large #s and diverse configs of memory-macros.
EXTEST only has to do with off-chip continuity testing, and thus only relates to the top-level external I/Os.
The main TAP-ctrlr is what typically handles this (consistent with the IEEE 1149.1 spec), but I also do not know if that spec or commercial JTAG control S/W allows for deviations from this notion.
A boundary-cell also must be inserted somewhere between each I/O pad-cell and the functional core-logic.
(but, not all I/Os will get this treatment, such as the actual JTAG I/F ports and maybe other special dedicated-test I/Os)
I do not know how you have inserted these boundary-cells, but they use control signals that would be fed from a TAP-ctrlr.
Determining if that TAP-ctrlr is solely the top-level one might help answer your question.
But again, it seems odd to me that you do not have someone involved in the design that already has the answers you seek.