OGC API Features has a monolithic conformance class (section 7) that defines everything in OGC API Common Part 1 and Part 2 + the capacity to manage items (http://www.opengis.net/spec/ogcapi-features-1/1.0/req/core)

Proposal:

Duplicate the part of section 7 that specifies items without changing anything, make it depending on OGC API Common and create a new common part that will be called, OGC API common - Part X - Items (equivalent to OGC API Features Part 1 core Items fragment). Individual requirements will maintain exactly the same URI as today.

The reason A: New OGC APIs Documents.

Any OGC API that wants to use "items" cannot use "common". For example, lets imagine that somebody wants to create an OGC API tables. Since the natural thing to do is use collections for tables and items for records in tables (rows), it cannot use common.
If OGC API feedback (GUF.SWG) of OGC API requirements (GONAR), wants to use OGC API records, it is forced to manage items so it need to include OGC API Features that defines everything in common part 1 and 2 so it cannot use OGC API common.

The reason B: Web API instances with features and common are impossible

Any Web API instances that wants to conform to OGC API Features and any other OGC API that uses Commons is forced into a contradiction as in its conformance page it cites OGC API Features Section 7 and OGC API Common Part 1 and 2 conformace classes that have requirements that overwrite each other for the landing page, the conformance page and the collections pages, creating a complete mess of redundant tests that could be potentially contradictory (remember that OGC API Features SWG does not want to adopt common in a revision of Feauture Part 1 core because some alleged contradictory requirements with OGC API Common). In my opinion this will create contractions in any implementation of OGC APIs using features and coverages or processes at the same time due to dual dependencies.

To me, the only solution is the one in the "Proposal" above. Since the requirements will be identical, I see no reason to object to it.