Those files are brought by autotools (automake --add-missing, autoreconf), and
the autotools maintainers update them regularly to add support for newer platforms.
This is why eg. most Debian packages (including the libsdl2 package) update them
using autoreconf while building (archs like *-kfreebsd or ppc64le-* for example
are not found by older config.* versions).

Today the SDL hg repo contains a very old version of those scripts (which means
many packagers have to override them), but modified.
If someone was to update those scripts in hg (which was last done in 2012), this
would interfere with the support for raspberrypi, emscripten, and "Chrome's native
client backend".

As far as I'm concerned, this means that building a libsdl2 package on Raspbian on
a rpi won't compile the RPI video driver.

config.* patches should be directed to their authors, GNU automake maintainers.
But here the rule that says that all boards featuring BCM2708 and BCM2709 running Linux
are RasperryPi's seems overreaching.

That value returned by the modified config.guess is used for 2 things:
* using the libs in /opt/vc, which could be better detected by a specific compilation test
  (checking for vc_dispmanx_resource_create ?)
* activating the RPI video driver, which could probably just depend on the result of
  the former test

... and thus at first sight it looks like the proper solution is just to use standard
autoconf checks, and that in fact no change to config.guess are needed.  Support for
the other two platforms will surely need to be adjusted similarly.


As a sidenote, keeping the generated files in the repository is what allowed the situation
to happen.  This is also the reason why in SDL2 trunk configure is desynchronized from
configure.in.  Many projects have chosen not to track those generated and copied files
to avoid those and other problems.