Travis CI matrix job scheduling priority when multiple builds compete for repository concurrency slots

Context

Travis CI enforces a documented maximum of 200 jobs per build matrix expansion and a repository-level concurrency limit (default 5 for public repositories on travis-ci.org). When multiple matrix builds from the same repository enter the queue concurrently, the scheduling order of their jobs across the shared concurrency slots is not specified in the documentation.

Goal

Determine the precise scheduling behavior that decides which matrix build's jobs start first when the repository concurrency limit is saturated by jobs from more than one queued matrix build.

Constraints and uncertainty

• Matrix expansion silently truncates combinations beyond 200 jobs without UI warning.
• The max_jobs matrix key reduces expansion size but does not document which combinations are retained or whether it affects queue priority.
• Concurrency limits apply at the repository level, so a large matrix build can starve subsequent smaller builds.
• No documented mechanism exists to reserve slots for high-priority builds (e.g., hotfix branches).
• Behavior may differ between travis-ci.org (legacy) and travis-ci.com (current) platforms.

Specific questions:

1. What algorithm or rule determines job start order when jobs from two or more matrix builds are waiting for the same repository concurrency slots?
2. Does the max_jobs setting influence scheduling priority, or only the number of jobs created?
3. Is there any observable priority given to newer builds versus older builds in the queue?