If so, it seems like it might be a big step backward for portability. One of Emacs' big advantages has been that it (and most of it's packages) work on every major desktop operating system. I share a common configuration between Linux and Windows. If this weren't possible I'd probably start looking for a different editor.
Allowing new packages to support platform specific FFI is not going to decrease the portability of the existing ecosystem. In addition, I don't think there is anything precluding FFI calls from working on multiple platforms so long as those libraries are available.
And this is the key part. As soon as we start getting Linux only packages that depend on some library easily available only on Linux, Windows users will be pushed off.
So far Emacs has been, for many users, nice abstraction over the OS. As soon as I'm not able to use the same packages and have the same setup on both Linux and Windows, I won't use it anywhere and start looking at the alternatives.
How is this any different than functionality that requires a specific executable to be called from Emacs. Some of those executables are platform specific. Last I checked using ispell on windows meant playing games with cygwin or some other fix.
The purpose of this is not to limit functionality to a specific platform, it's to expand the capabilities of Emacs. My understanding is FFI is intended to work on all platforms that Emacs support, so it just means the library authors need to provide platform specific support, just the same as they do with packages that depend on specific binaries in the path.
Throwing out a new feature that provides obvious benefits because of imagined future packages that may choose against being platform agnostic seems rather short sighted.
There actually wasn't very much discussion on this. There are many features of Emacs that can be turned on or off based on the system, and this is just one more.
