Blender 5.2 refuses older VRM extension builds because blender_version_max is exclusive

The gate runs after the unpack. Blender writes the files, reads `blender_manifest.toml`, compares the declared `blender_version_max` against the running build, and refuses to activate ^[11]. The console prints the comparison in full: "ERROR vrm: This Blender version (5.2.2) must be less than the maximum version (5.2.0)" ^[9]. Strict less-than, against a declared 5.2.0, so 5.2.0 is out and so is every patch above it ^[13].

The off-by-one is documented. The Blender manual's manifest example carries the comment "# Optional: Blender version that the extension does not support, earlier versions are supported." above the line `blender_version_max = "5.1.0"` ^[12]. In my view that is the right default for a host that removes API in major releases; the obligation it creates is on the add-on side. An extension that wants to run on 5.2 LTS has to declare 5.3.0, which is what 4.7.1 declares, and the 5.3.0 alpha refuses it ^[14].

Blender 5.2.2's Extensions panel does not list the VRM entry at all, and an absent row is hard to search for ^[10]. The panel queries the extensions.blender.org API filtered by Blender version, and the filtering happens server side ^[24].

Each of the 32 cells ^[26] got a fresh `BLENDER_USER_RESOURCES` directory, so no cell inherited state from the one before it or from the author's own Blender config ^[17]. The dev.to post also pulled the manifest from every release tag: `blender_version_min` is 4.2.0 on all of them, and only the upper bound ever moved ^[15]. Reading the v4.0.0 tag alone would have hidden a group of 22 tags sharing a 5.1.0 bound ^[16], roughly 31 percent of the 71-tag history ^[27].

Whether the legacy result transfers depends on what your file does. Version 4.3.0 enabled on 5.2.2 and on 5.3.0 alpha and passed the roundtrip on both ^[19], where the roundtrip is importing a VRM file, exporting it, and importing the export again, for a VRM 0.x and a VRM 1.0 sample ^[18]. To get the same pass on a production scene, the work has to stay inside the code paths those two files exercise. The author says as much: activation plus a two-file roundtrip does not show that the blocked combinations are free of other API incompatibilities ^[20].

One combination is genuinely broken, and the add-on's own code is what catches it. Installed the legacy way on 5.2.2, version 3.9.0 raises "ImportError: cannot import name 'ShaderNodeTexPointDensity' from 'bpy.types' (unknown location)" ^[21], then prints its own guard line, "This add-on is not compatible with Blender version 5.0 or later. Your current version is 5.2.2." ^[22]. Blender 5.0 removed that type, 3.9.0 imports it at module load, and there is no install path that makes the pair work ^[23]. The manifest gate, by contrast, blocked 4.x combinations that imported and exported both sample files ^[19].