A path must reach an accepted anchor
A common display orders the target, intermediate CAs and a root, while validation can be described from anchor toward target. Issuer relationships and signature checks must connect each step; adjacent files or matching issuer names alone do not establish that relationship.
A server cannot add a trusted root merely by sending a self-signed certificate. RFC 5280 treats the anchor as an independent input. If a self-signed certificate carries anchor information, that anchor certificate is not itself part of the prospective path defined by the algorithm.
References: [1]
Building a path differs from validating it
A validator needs a prospective sequence before checking whether it satisfies the given conditions. RFC 5280 leaves obtaining that sequence outside its validation algorithm. Repository retrieval, cached certificates and peer-supplied intermediates provide candidate material.
Acceptance also depends on the chosen anchor, date and policy inputs. Finding a chain is therefore different from having the application accept it. Trust configuration or constraints can change the outcome, and a complete list supplied by a peer is not already a validated path.
References: [1]
CA authority and final service identity still matter
An intermediate certificate does not gain unlimited issuing authority just because its key verifies a signature. basicConstraints identifies CA authority and optional path-length bounds, while keyUsage restricts purposes. Name constraints, validity and unsupported critical extensions can also invalidate a path.
Certificate policy processing is another component. RFC 9618 updates its algorithm to avoid potential exponential behavior in the older procedure, rather than requiring that old tree implementation. A validated path still leaves TLS clients to match the intended service name under RFC 9525.