Nice catch, please commit it.
+ bump port revision

It fails if EXAMPLES and PREEDIT both on (both are non-default).
Patch:

diff -ur graphics/glfw/Makefile.orig graphics/glfw/Makefile
--- graphics/glfw/Makefile.orig
+++ graphics/glfw/Makefile
@@ -10,7 +10,7 @@
 LICENSE=       ZLIB
 LICENSE_FILE=  ${WRKSRC}/LICENSE.md

Simple way to introduce specific devel features avoiding master/slave and flavors ports.

Today on ports@ I have read something that might be applicable to this case:

In D44490#1014853, @eduardo wrote:

Myabe flavour can help.

flavors will have same problem as separated ports since they cannot be installed both in same system.

Myabe flavour can help.

Create USES=glfw with option devel: USES=glfw:devel.
If user want to use glfw:devel then he must set DEFAULT_VERSIONS+=glfw=devel.
In default configuration lwjgl3 is broken - it's bad.
I forgot that a lot of users use pkg instead of build from ports.
Same issue if add option with EXTRAPATCHES to the port.

In D44490#1014841, @eduardo wrote:

This problem can be solved by using USES and default version. Is this port so popular that it makes sense to make a USES for it?

Can't get it, could you explain better or add an example?

This problem can be solved by using USES and default version. Is this port so popular that it makes sense to make a USES for it?

In D44490#1014839, @eduardo wrote:

Hello,

My first impression is that adding 14 upstream patches to a port based on a release is not good.
We usually use patches to fix something and in this case we are promoting glfw -> glfw-devel.

My sugestion is to create a glfw-devel so we can use devel features in ports that needs it.

My first impression is that adding 14 upstream patches to a port based on a release is not good.
We usually use patches to fix something and in this case we are promoting glfw -> glfw-devel.

Better handle with libffi.

Don't forget to add the port to games/Makefile.

Replaced static link with libffi with dynamic!

Explanation why upstream use static link with libffi: https://github.com/LWJGL/lwjgl3/issues/421#issuecomment-1992147241
I also ask to help explain to upstream what ports are and what the work of maintainers is.
My English is too bad to do this correctly even with the help of online translators.

Statically linking to libffi is still a show-stopper. It shouldn't be required.

In D44263#1009719, @tcberner wrote:

I get a linker error on current:

   [Linker] ld: error: relocation R_X86_64_32S cannot be used against symbol '.Lswitch.table.ffi_prep_cif_machdep_efi64'; recompile with -fPIC
   [Linker] >>> defined in /wrkdirs/usr/ports/games/lwjgl3/work/lwjgl3-de8bd86/bin/libs/native/freebsd/x64/org/lwjgl/libffi.a(ffiw64.o)
   [Linker] >>> referenced by ffiw64.o:(ffi_prep_cif_machdep_efi64) in archive /wrkdirs/usr/ports/games/lwjgl3/work/lwjgl3-de8bd86/bin/libs/native/freebsd/x64/org/lwjgl/libffi.a
   [Linker]
[...]

I get a linker error on current:

Upstream suggest a better way to prevent install conflict with devel/libfmt: https://github.com/KhronosGroup/KTX-Software/issues/786#issuecomment-1972410244

Remember to add this new port to the category Makefile.

Remember to add this port into graphics/Makefile

Forgot to remove unused USE_LDCONFIG=yes.

https://github.com/KhronosGroup/OpenXR-SDK-Source/issues/241#issuecomment-1966404332