Say a user has built a workspace and subsequently runs colcon test. The user then modifies a number of files in the workspace and again invokes colcon build and then colcon test. Ideally, one could expect packages that are were modified, as well packages above those modified, to be rebuilt. Then for testing, only those packages rebuilt, would be retested. Thus the caching of build and test would be maximized, yet still encompassing all changes to the workspace since the previous build and test.

Would this be achievable using mixins and extensions? Or would core changes be required?

I'm thinking an extension could retain a digest-manifest for all files in the workspace, so it could be fully aware of file level changes. Those file changes could then be associated to package names that then could be passed to colcon build and test arg, e.g.

colcon build --mixin incremental
->> expands to ->>
colcon build --packages-above <modified_packages> \
    --packages-select-build-failed

colcon test --mixin incremental
->> expands to ->>
colcon test --packages-above <rebuilt_packages> \
    --packages-select-test-failures

BTW, are the sets of packages captured by each arg OR'd or AND'd together?
And would something like incremental clean vs incremental dirty be helpful for specifying whether effected packages should be cleaned or not prior to build or test? Related: #37