FindOpenAL explicitly includes the "include" suffix in all its PATH_SUFFIXES list entries. This appears to be aimed at the HINTS and PATHS entries, which don't contain an "include" suffix. This breaks searching standard paths such as /usr/include because find_path() constructs these standard locations by itself appending "include" to a list of standard top-level locations such as /usr. Hence, FindOpenAL will end up looking for al.h in /usr/include/include/AL, /usr/include/include/OpenAL, etc.
This likely slipped through the cracks until commit e93ac6fb removed the usual standard paths from any "PATHS" variables specified to find_*() commands. That change didn't take into account FindOpenAL's non-standard usage.
I'm not clear why FindOpenAL doesn't just append "/include" to its PATHS and HINTS entries rather than including them in the PATH_SUFFIXES list, but on the off chance doing so breaks things for some reason, this change opts to simply add in the actual OpenAL include path suffixes to the PATH_SUFFIXES list after the current entries, re- enabling the ability to find OpenAL headers in the standard path prefixes in a way that least perturbs existing behavior.
Topic-rename: FindOpenAL-std-includes