Upgradeable `init` vs `init_unchained` - a follow up question to a closed thread

Smart Contracts
1

I was just looking through the thread regarding __ContractName_init() versus __ContractName_init_unchained() found here. It doesn't let me post this to that thread since it's solved, so apologies for the reopening!

The initial reply discusses that calling an inherited module and running the non-unchained init would trigger all it's necessary inherited inits correctly. But that doesn't seem to always be the case necessarily?

For example, AccessControlUpgradeable (ACU) inherits several modules that each have their own initializer to call. For this, ACU has it's, but so does ContextUpgradeable & ERC165Upgradeable - neither of which are called by ACU's __AccessControl_init() - these don't take any state changing actions, so since they're not called within the ACU module, do these not even need to be called at all? Or should they be hit within the main contract's initializer, which would look like this:

function initialize() public initializer {
        __UUPSUpgradeable_init_unchained();
        __AccessControl_init_unchained();
        __Context_init_unchained();
        __ERC165_init_unchained();

Or should one or two of those inheritance init calls not be unchained, namely UUPS & ACU? Is it normal to not include the Context & ERC165 inits?

Thanks!