Should `includes:` field be removed from the specification?

GHC has ignored it since GHC 6.10.1 (November 2008) and Cabal has not supported GHC versions before GHC 6.12 since `Cabal-2.0.0.2` (July 2017). Given the passage of time, perhaps the field should be dropped from the Cabal Package Description Format Specification?

Be aware that `Win32` still uses it (even though it has no effect) and other packages use it because they have simply copied `Win32` (for example, `mintty` and `ansi-terminal`).

EDIT1: Elsewhere, @hasufell has identified that the discussion above is GHC-centric. In that regard, it is true that the Cabal User Guide still [states](https://cabal.readthedocs.io/en/stable/package-concepts.html#portability):

> One of the purposes of Cabal is to make it easier to build packages on different platforms (operating systems and CPU architectures), with different compiler versions and indeed even with different Haskell implementations. (Yes, there are Haskell implementations other than GHC!)

EDIT2: There are other examples where parts of the Cabal Package Description Format Specification have been deprecated and/or removed as things have developed:

* `hs-source-dir`: deprecated (in favour of `hs-source-dirs`) 2.0, removed 3.0
* `extensions`: deprecated (in favour of `default-extensions`) 1.12, removed 3.0
* `build-tools`: deprecated (in favour of `build-tool-depends`) 2.0, removed 3.0

EDIT3: GHC's `CApiFFI` language extension was introduced in GHC 7.6.1 (that is, after GHC had begun to ignore Cabal's `includes:` field). I have not identified anything in the documentation to suggest that GHC began to pay attention again to the field on its introduction.

Start by reading the Cabal Package Description Format Specification and the User Guide's portability section, then inspect how `includes:` is used by Win32, mintty, and ansi-terminal. Determine whether the field is still needed for non-GHC Haskell implementations and what compatibility implications removal has. Done means the specification's status is resolved and the affected documentation and examples are consistently updated.

Written by the indexing model from the issue text.