Getting lib32 porting effort unstuck

WINE requires 32-bit libraries for many programs.  The current system 
used by the WINE port is to require the user to run a helper script 
which uses pkg to fetch and install i386 packages to the home 
directory.  It is not ideal.

The WINE project's promised WoW64 thunks for 32-bit processes to use 
64-bit libs has been in "almost there but not quite" status for years.  
The motivation to maintain 32-bit libs for WINE remains.

Several proposals have been made for 32-bit library ports:
- A single i386-libs port uses a chroot to build many libraries from 
ports tree which are then installed/packaged as one port. Unacceptable 
since a port must not require root to build. 
https://reviews.freebsd.org/D14721
- Create i386- slave ports of all required libraries.  Filling the ports 
tree with ~100 arch-specific additional ports seems unacceptable. 
https://github.com/shkhln/freebsd-lib32-companion-ports
- Add -i386 flavor to all required library ports.  Clutters ports' 
Makefiles and may conflict with existing FLAVORS uses.  Not using 
FLAVORS as intended.  https://reviews.freebsd.org/D16830
- Write a single i386-libs port.  Each library is built as a separate 
package as a FLAVOR of i386-libs.  Unconventional usage of FLAVORS.

All reviews and efforts on this seem to be dead as a result of 
uncertainty over whether the implementations are acceptable within the 
existing ports framework.

For thoroughness, some of the ideas previously discussed which are 
surely unworkable and don't deserve any further consideration:
- Create an amd64-lib32 repository that may be used by pkg alongside 
amd64 repository.  Completely outside of normal dependency mechanisms 
and leaves direct users of ports tree without a simple procedure to 
build i386 libs.
- Ports overlay
- Have an i386-libs metaport do evil variable manipulation of port 
framework dependency recursion to create i386- variants on the fly. 
Maintenance headache and incompatible with poudriere.  Procedure for 
rebuilding specific ports is non-obvious to the user.

Single i386-libs port with each library built as a FLAVOR seems to be 
the least bad option.  However any work on it, even a minimal working 
review, is a waste of time if this particular usage of FLAVORS is dead 
on arrival to portmgr@.

WINE port Makefile example:
LIB_DEPENDS= ... 
${LOCALBASE}/lib32/libfontconfig.so:emulators/i386-libs@x11-fonts__fontconfig

emulators/i386-libs/Makefile:

PORTNAME=       i386-libs
CATEGORIES=     emulators
MASTER_SITES=
DISTFILES=

LIB32_PORTS=    \
                 x11/libXrender \
                 x11/libX11 \
                 x11-fonts/fontconfig \
                 security/gnutls \
                 print/freetype2 \
                 graphics/vulkan-loader \
                 graphics/libGLU \
                 devel/sdl20 \
                 graphics/mesa-libs \
                 (... many more ...)

FLAVORS=        meta ${LIB32_PORTS:S,/,__,} # category/portname -> 
category__portname

# ${FLAVOR}_*_DEPENDS to be derived from a ${MAKE} -V into referenced port.
# emulators/i386-libs is not a slave port.

Considering the lack of better options and the situation that FLAVORS is 
the only currently supported mechanism for a single port to build 
several packages, will the slightly unconventional use of FLAVORS be 
acceptable provided the port conforms to quality standards in all other 
aspects?