Currently, there is not a unified way to mark lint checks as experimental. Currently, we have a single rule that is experimental, and that is implemented via control through a build arg. Making a flag per rule we may want to implement but not have generally available isn't sustainable.

Proposal

Add an Experimental field to rules. By default, rules with this field set to true will not be evaluated. This would

RuleCopyIgnoredFile = LinterRule[func(string, string) string]{
	Name:        "CopyIgnoredFile",
	Description: "Attempting to Copy file that is excluded by .dockerignore",
	URL:         "https://docs.docker.com/go/dockerfile/rule/copy-ignored-file/",
	Format: func(cmd, file string) string {
		return fmt.Sprintf("Attempting to %s file %q that is excluded by .dockerignore", cmd, file)
	},
	Experimental: true,
}

Enabling Experimental Rule Checks

Experimental rules, by default, will not be run. In order to control the enabling of experimental rules, we can extend the current directive for lint controls with an experimental key, as in examples below:

#check=skip=StageNameCasing,NoEmptyContinuations;experimental=CopyIgnoredFile
#check=experimental=all
#check=skip=all;experimental=CopyIgnoredFile

The expectation is that the experimental key accepts similar input to the skip key: either a comma-separated list of experimental rules, or all, where the former enables only the experimental checks listed and the later sensible enables them all.
The skip flag would not overwrite the experimental flag - something like #check=skip=all;experimental=CopyIgnoredFile would still run the CopyIgnoredFile, since it's being explicitly enabled here.