"Odd" design regarding the new Pathing feature

[CodeHatchling]

Unless I am not undestanding the interface correctly, the pathing feature leaves a lot to be desired with how it is currently implemented.

1. In order for an audio source to use pathing, it must have a direct reference to the probe batch through which pathing occurs.
2. As implied by 1), in order for pathing to work through the entire level, all of the probes for the entire level must exist in one probe batch.
3. As implied by 1), even if the level could be reasonably split into separate probe batches, with the expectation that sound does not propigate between them, it requires that the developer implements a system of spatial querying in order to determine the most appropriate probe batch an audio source should be associated with at creation time and as it moves. (In simple cases like floors of a dungeon, this works fine. A more complex level with arbitrary layout, not so much.)
4. As implied by 2), if level B is additively loaded into level A, pathing cannot occur between them as they must use separate probe batches.
5. As implied by 2), you are very limited in what sort of probe layouts you can use as they must be contained within one batch, unless you write your own code that allows for custom probe placement.

My expectations were:

• All "nodes" of the graph (in our case, probe batches) are considered when pathing, similar to how path-finding algorithms like A* work.
• A nearest-neighbor lookup is performed between the audio source and the node graph to automatically determine where pathing should start or end.

Also, I'm assuming that pathing is used to estimate the sound diffration you experience with real sounds, where a sound in the adjacent room placed on the opposite side of a wall sounds like it is coming through the door, even though its shortest path is through the wall. I'm assuming that the path length determines the attenuation and absorption of this sound using the same distance/attenuation curves as used by direct sounds.

While this is probably wildly out-of-scope, I was kind of hoping "baked pathing" was a way to bake reverb, reflections, directionality etc. and was analogous to "baked path tracing" such as what you'd get with lighting via stuff like Enlighten. Perhaps there'd have to be N^2 points of data describing direction, reflections, reverb, etc. experienced by the listener, given the position of the listener (as approximated by the nearest probe's position) and the position of the sound (also approximated by its nearest probe position). Currently it seems as though this data can only be baked in cases where this data is N^1, that is, either the listener or the sound source is static. Anything N^2 is understandably scary.