I think there are some some technical measures in ISO26262-6:2018 where many look away or even sometimes “swept under the carpet“. I would like to point here mainly to Table 3 “Principles of software architecture design”

I personally rarely saw a company using some software metric tooling and reference values to claim compliance with methods 1d or 1e, for instance. Software metrics, regardless of how questionable could be in the „software world“, they deliver a good idea on code quality. What is meant by that? That the software shall be correct (to correspond to specifications), reliable (probability that will execute for a period of time without failure), cost-effective and delivered on time. Last two parameters here are conditioned and determined by its complexity, maintainability and reusability.
It is amazing how a book written in 1976, like Myers: “Software Reliability: Principles & practices”, when even C language was in its inception, is now, not only valid, but a reference quoted by the IEC61508-7:2010 and a source for 1b, 1d and 1e in the table above.
Code cohesion and coupling , though qualitative parameters, are key indicators on the level of complexity and reusability. Former one describes how related the functions within a single are, and latter refers to the interdependencies between the modules within the whole software.

They we’re invented in the late 60s by the “Yourdon, Myers, Stevens, Constantine” computer science “school of thought” and later also elaborated in the book mentioned above.
Is not the purpose of current writing to describe code strength (cohesion) or coupling in detail, but to draw the attention towards a more careful treatment of such measures as those in Table 3. A great initiative in this sense, in the automotive industry, was the former HIS association releasing a paper (link is to Exida blog posting, commenting the paper) on software metrics.
Indeed, this is rather targeting modelling and coding guidelines (so, Table 1 in ISO26262-6), than software modularization and complexity mangement, but is setting at least an example on how this matter can be considered.
Maybe one of the clumsy things about ISO26262 is that it does not provide any overview or a more thorough explanation of its methods and measures listed in the tables across all of the parts, and has no part 7 (Overview of techniques and measures) like in IEC61508. It only indicates the means to be used to achieve a specific safety integrity but does not guide on how to use them.