To All, (especially @sebavan thank you for your quick reply)
Warning: long post coming up, ha. But I feel the need to explain the whole issue so we can try to fix it or at least make a work-around.
Just to bring everyone up to speed who might be reading this thread at this point, I received an issue on our GitHub repo saying a glTF was failing to load. The console had an error message from Babylon that I didn’t quite understand. Thank you @sebavan for telling me what that error message means - I think I follow you now! 
Sorry if you all know this info already, but basically all 3D models (glTF models in our case) are built up from various triangles, each triangle having 3 vertices, and each of those vertices having some sort of info about them that makes them unique. This vertex info is called ‘attributes’ (historically named I believe from the early days of OpenGL?). These attributes (or vertex ‘details’) usually come in the form of ‘positions’ (where is this vertex located in space?), ‘normals’ (which way is the normal vector pointing for this vertex?), colors(what rgb color is this vertex?), and textureUV (what are the texture coordinates for this vertex when sampling the triangle’s material texture, if any?). There are other attributes that might or might not be present among different models, which brings us to this issue.
Basically the error that GitHub issue OP was getting was the result of feeding the geometry merging routine with 2 separate gltf’s (not usually a problem) but that had different sets of info, or attributes, associated with each model. Maybe one had a complete set of UV attributes, while the other did not even have any UV attributes listed at all - in other words ‘attributes.uv == undefined’ or something similar.
So when the merge function gets to this point, it doesn’t know how to handle the seemingly incompatible lists of attributes for the 2 different models. Understandably, you can’t expect Babylon to magically add a list of uv attributes to the model that didn’t have them from the modeling program exporter in the first place. Therefore, as it stands with Babylon (and now three.js has followed suit - I just checked), the merge utility function throws an error and halts program execution altogether.
Here’s the spot in the merge function: source
I agree that there should be some kind of warning in the console if the attribute names for all models don’t line up exactly, but I sort of disagree with both libraries (Babylon and Three) throwing an error and refusing to go further with program execution (basically a crash).
For instance, a year ago I was able to load a TRON tank gltf model that was composed of 5 or so different components. Just for reference, I went back just now and tried with the current version of three.js and its handy function ‘bufferGeometryUtils.merge(geometryList)’ . Keep in mind that this used to load just fine - here’s what I got:
Then I simply went inside the three.js buffer geometry utilities source code and commented out the ‘throw error’ part, basically saying ‘it’s ok, I know what I’m doing, just continue with merging anyway, lol’ and voila:
A gaudy pink (my color choice) metal TRON tank (lol) but it works and looks great! So even when the attributes for the various gltf’s did not match, it doesn’t appear to harm the library or the user’s program when execution just keeps moving along.
So, I did a similar test with Babylon - I disabled the line where it says ‘throw error(…’ if the attributes don’t quite match, and the issue OP’s composite model loads just fine:
Just for reference, here is a pic of the online glTF viewer with the same data:
You’ll notice though that the diffuse albedo color and wood textures are not present in our pathtracing renderer, even though they are defined inside the gltf file. This is another side issue that I will have to address: namely, when the textures are actual external files, everything is fine, but when the textures are somehow expressed as binary data Inside the single gltf file itself, my loading scheme can’t handle it. I’m so glad this OP gave me this example and brought this to my attention, because it’s exposing so many flaws in my code (lol!). 
So I guess the question is, if Babylon does in fact spot discrepancies between the attribute lists of 2 different geometries that it is trying to merge, what do we want to happen? If an error absolutely must be thrown, then we must tell the OP and other users, ‘make sure your modeling program exports similar data for all the components of your model that you want to later merge.’
Or we could soften the blow with a warning from Babylon in the console, instead of an error and terminating execution altogether - but I don’t think this will be a popular solution.
Or the last option, and needing most effort, would be to write a similar preemptive check that Babylon’s merge function does, and if we detect attribute differences, intercept it by giving ghost attributes to geometry that are missing these attributes, so that all models match. This doesn’t seem very tractable though.
Sorry, for the lengthy post, but I wanted everyone to be on the same page as to what is happening and the decisions we have to make.
Regarding why I must merge the geometries in the first place (@sebavan ), rather than just leaving them separate geometries, is because the way I have my triangle BVH acceleration structure set up is that it expects a flat list of all the triangles in the model or scene. The vertex array indices must increase as you go from triangle to triangle, until all have been listed. The BVH takes this complete list, and builds an efficient, balanced binary tree of bounding boxes (with matching increasing integer ID’s to their triangle counterparts, box[0], box[1], box[2], etc…) for fast and efficient ray casting inside the GPU shader.
Now it is possible that in the future we could just leave everything separate and have multiple gltf models in the scene, each with their own transforms, each with their own material lists, etc., sort of like users specify for typical WebGL rasterized Babylon scenes currently. It would be great to have 100’s of different models floating around - but each of those models needs its own BVH tree. And then all those smaller trees need to be grouped into an overarching scene tree - so essentially a 2-tiered BVH system - a series of bottom level BVHs and a large top level BVH. This is NVIDIAs proprietary solution by the way. I made some successful experiments on small scales with my Sentinel game remake (that has dozens of models moving around a path traced scene in real time), but I’m not quite there yet for true, generalized Babylon scenes that might have an arbitrary number of models and triangles that a typical user might want to add. For the time being, everything must be squashed down to a big, flat list of triangles and their associated vertex data.
Thoughts and comments are welcome as always. Thanks for listening to my rantings, ha! Hopefully we can find a solution that’ll suit most parties. 
-Erich
