Loading Amber driver with Mesa 24 ends with segfault (gbm_dri_device mismatch?)

I'm trying to integrate Mesa Amber with regular Mesa as a packager of Adélie Linux. Regular Mesa is working great. I pulled out a very old MacBook1,1 (the original Core Duo model, before 64-bit CPUs):

Host: MacBook1,1 (1.0)
Kernel: 6.6.58-mc2-easy
Uptime: 1 hour, 7 mins
Packages: 1687 (apk)
Shell: sh
Display (Color LCD): 800x1280 @ 60Hz
Terminal: /dev/pts/0
CPU: Genuine Intel(R)            1500 (2) @ 2.00 GHz
GPU: Intel Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller

and am seeing this when starting X and/or Sway:

Program received signal SIGSEGV, Segmentation fault.
0xb7ef4f23 in strlen (s=<optimized out>, s@entry=0x1010000 <error: Cannot access memory at address 0x1010000>) at src/string/strlen.c:17
17	src/string/strlen.c: No such file or directory.
(gdb) bt
#0  0xb7ef4f23 in strlen (s=<optimized out>, s@entry=0x1010000 <error: Cannot access memory at address 0x1010000>)
    at src/string/strlen.c:17
#1  0xb7ef4c85 in strdup (s=0x1010000 <error: Cannot access memory at address 0x1010000>) at src/string/strdup.c:6
#2  0xa9d3e1e5 in dri2_initialize_drm (disp=0xa9caa010) at ../src/egl/drivers/dri2/platform_drm.c:731
#3  0xa9d34738 in dri2_initialize (disp=disp@entry=0xa9caa010) at ../src/egl/drivers/dri2/egl_dri2.c:1181
#4  0xa9d2a3e2 in eglInitialize (dpy=0xa9caa010, major=0x0, minor=0x0) at ../src/egl/main/eglapi.c:636
#5  0xb73e3bb4 in glamor_egl_init (scrn=0xb795e030, fd=13) at ../glamor/glamor_egl.c:960
#6  0xb74549d6 in try_enable_glamor (pScrn=0xb795e030) at ../hw/xfree86/drivers/modesetting/driver.c:945
#7  PreInit (pScrn=0xb795e030, flags=0) at ../hw/xfree86/drivers/modesetting/driver.c:1172
#8  0x00563c30 in InitOutput (pScreenInfo=0x68d360 <screenInfo>, argc=1, argv=0xbfe214e4) at ../hw/xfree86/common/xf86Init.c:478
#9  0x004a671a in dix_main (argc=1, argv=0xbfe214e4, envp=0xbfe214ec) at ../dix/main.c:190
#10 0x00477a32 in main (argc=1, argv=0xbfe214e4, envp=0xbfe214ec) at ../dix/stubmain.c:34
(gdb) frame 2
#2  0xa9d3e1e5 in dri2_initialize_drm (disp=0xa9caa010) at ../src/egl/drivers/dri2/platform_drm.c:731
731	   dri2_dpy->driver_name = strdup(dri2_dpy->gbm_dri->driver_name);
(gdb) p dri2_dpy->gbm_dri
$1 = (struct gbm_dri_device *) 0xb7961cd0
(gdb) p *dri2_dpy->gbm_dri
$2 = {base = {dummy = 0xb7448310 <gbm_create_device>, v0 = {backend_desc = 0xa9d9c940, backend_version = 1, fd = 13, 
      name = 0xb72e6301 "drm", destroy = 0xb72deea0 <dri_destroy>, 
      is_format_supported = 0xb72e0960 <gbm_dri_is_format_supported>, 
      get_format_modifier_plane_count = 0xb72e05b0 <gbm_dri_get_format_modifier_plane_count>, 
      bo_create = 0xb72df750 <gbm_dri_bo_create>, bo_import = 0xb72df360 <gbm_dri_bo_import>, 
      bo_map = 0xb72df1f0 <gbm_dri_bo_map>, bo_unmap = 0xb72df110 <gbm_dri_bo_unmap>, bo_write = 0xb72e0090 <gbm_dri_bo_write>, 
      bo_get_fd = 0xb72df0a0 <gbm_dri_bo_get_fd>, bo_get_planes = 0xb72e0540 <gbm_dri_bo_get_planes>, 
      bo_get_handle = 0xb72e07e0 <gbm_dri_bo_get_handle_for_plane>, bo_get_plane_fd = 0xb72e0a50 <gbm_dri_bo_get_plane_fd>, 
      bo_get_stride = 0xb72e03b0 <gbm_dri_bo_get_stride>, bo_get_offset = 0xb72e0690 <gbm_dri_bo_get_offset>, 
      bo_get_modifier = 0xb72defe0 <gbm_dri_bo_get_modifier>, bo_destroy = 0xb72def30 <gbm_dri_bo_destroy>, 
      surface_create = 0xb72dec80 <gbm_dri_surface_create>, surface_lock_front_buffer = 0x0, surface_release_buffer = 0x0, 
      surface_has_free_buffers = 0x0, surface_destroy = 0xb72dec40 <gbm_dri_surface_destroy>}}, driver = 0xa9d9c610, 
  driver_name = 0x1010000 <error: Cannot access memory at address 0x1010000>, software = false, screen = 0xa9d9c420, 
  context = 0x0, mutex = {__u = {__i = {0, 0, 0, 0, 0, 0}, __vi = {0, 0, 0, 0, 0, 0}, __p = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}}, 
  core = 0xa9d721b0, dri2 = 0xb72ea010 <gbm_dri_screen_extensions>, fence = 0x0, image = 0x0, swrast = 0x0, flush = 0x0, 
  driver_configs = 0x0, loader_extensions = 0x0, driver_extensions = 0x0, lookup_image = 0x0, 
  validate_image = 0xb72e6900 <gbm_dri_visuals_table>, lookup_image_validated = 0x16, lookup_user_data = 0x0, get_buffers = 0x0, 
  flush_front_buffer = 0x0, get_buffers_with_format = 0x0, image_get_buffers = 0x0, swrast_put_image2 = 0x18, 
  swrast_get_image = 0x5aa600 <DRIBlockHandler+22>, wl_drm = 0xa9d1c000, visual_table = 0xb7961e74, num_visuals = -1445602728}
(gdb) 

The structure members do not look correct to me, and indeed, if I cast driver to a char* it appears to be driver_name:

(gdb) p (const char *)dri2_dpy->gbm_dri->driver
$4 = 0xa9d9c610 "i915"

not to mention the fact that validate_image is set to gbm_dri_visuals_table and the member after it (lookup_image_validated) looks to be num_visuals.

I looked to other distros and found myself more confused. Arch makes Amber conflict with regular Mesa (which doesn't work for us, because we want to ship one bootable image that will work everywhere); Ubuntu seems to disable GBM (which would remove ability of Amber devices to run Wayland compositors); Gentoo seems to do exactly what we do and I don't see any bugs filed there about this.