Hi Hogster and thanks for the input!
TL/DR: I really do waffle on here, and none of it is likely to be relevant to anyone who just wants to use the integration  so it can be safely skipped! If you’re interested in helping / understanding my pathology though, read on…
This is one of those areas where coming up with ideas is one thing but actually implementing them to find out if they work is quite another thing altogether!
The data we get is a set of “distance” measurements, which are:
 subject to the dark magiks of RF propagation.
 very noisy, with noise that is massively skewed to overshoots (ie, almost all measurements are actual distance plus a positive noise figure, a few might have nearzero noise, and a tiny amount might have a negative noise offset due to inphase reflections).
 unreliably delivered. They might be late, or more likely missing altogether. A missing measurement is also indistinguishable on its own from an infinite distance measurement.
The unreliable delivery and asymmetric noise cause trouble straight away with the classical algorithms like Kalman filtering or even just plain averaging/smoothing. Luckily though, accurately putting certain things at the exact same place as a certain other thing, in as short a time as possible, is something that militaries are quite interested in, so there is (funded) research around, for those able to read the math. I am not skilled at the math, but I can sometimes grok the principles.
Re users drawing maps, that is a (long term) possibility, but I have no plans to do that any time soon. The main thing is that I think it will be unnecessary, but I’m in the wrong part of the DunningKreuger curve to know for sure. I am (un?)reasonably confident that the system should be able to “solve” the spatial arrangement, and potentiallyinaccurate user measurements would make that more difficult rather than less. I could be wrong, though. Ultimately I expect we’ll have our own “point cloud” which could then be “pinned” to a user’s map using translate/rotate/scale values.
My thinking is that if two proxies each measure the distance to one beacon, then the distance between the beacons can not be further than the sum of the two measurements (this is called “Triangle Inequality”). If the beacon moves around, that minimumestimate will gradually improve, and if the beacon is placed at one of the beacons, we get our “answer” for the distance between those two proxies. From now on, when we receive measurements to that beacon, we have the lengths of three sides of a triangle from those proxies, so can arrive at two solutions in space for the beacon, relative to the proxies (the location is mirrored about the axis between the proxies). You can think about this by drawing circles  choose an arbitrary point as proxya. Draw a circle from that point with the radius of the distance between proxya and proxyb, and choose anywhere on that as the location of proxyb. Now if you draw a circle centred on each proxy for the beacon distance measured, those two circles should intersect at two locations, either side of the line between the proxies (or on the line, occasionally). In a way you have the “actual” position, and an ambiguous “reflection” of that position. The reason I think this is “better” than a userdefined map is that the distances then all come from the same, faulty system  rssi measurements, which I think might be easier to integrate than two different measurement systems. Some basic constraints from user input might be really helpful though, things like “these three proxies all lie along a single line, and this fourth proxy is on a line perpendicular to them, intersecting at the first one”, say.
When we have distance “measurements” between three points, we have solved the shape of that triangle but not which “reflection” of that triangle we have. If we bring in another proxy we get a third “fixed” point and solve where the beacon is in relation to those three points (in a 2D plane).
Once we achieve this, it stands to reason we can achieve this with every combination of proxy and beacon, at which point we have “solved” the spatial arrangement of all the beacons and proxies, relative to each other. At that stage one just needs to define a point in real space for any proxy, and an angle in real space to point at another proxy and the entire “cloud” is now aligned with real space. eg “consider my office proxy as being at [0,0,0], and the laundry proxy is exactly North of that”.
This is why I think we don’t need a usersupplied map to solve the space, and you can probably see that with the noisy nature of the data, trying to fit a userdimensioned map adds a lot of complexity to something that hasn’t yet solved its existing complexities!
I’m much keener for being able to visualise a 3D cloud of points in HA rather than going down the userprovided floorplan, but it would be a long time before I have time for either, I suspect.
So, being doable for a single floor seems… waves hands likely? Solving in 3D for multiple floors is… less certain… certainly harder. I think that mathematically (as far as I can think mathematically!) there’s no reason why it shouldn’t work. With distances from two proxies you get a circle perpendicular to the plane (so it looks like two points in 2D), while distances from three proxies, if perfect, give you 2 points in 3D, which looks like a single point in 2D. Adding another proxy that’s not in the same plane (say, on a different floor) then gives us a hint at the “point”'s distance from the original plane. Except, none of these “points” are actually “points”, they’re all clouds of confusion, due to the noise and uncertainty. I think that adding that third dimension is likely stretching the already lowquality data a lot more than going to two did. I still think it’s possible, just laying out the difficulties so people can manage their expectations!
As for at which point these uncertainties cause everything to fall apart (or simply be less than useful) I am not sure, but I am pretty confident that there is a lot of useful space between “not perfectly correct” and “entirely busted”.
My hesitation around solving for 3D is that while we work in only two dimensions, we sort of just fold the third dimension into the noise and try to ignore it (since any distance in the third dimension just causes an increase in all the measurements from the origin plane, which is exactly what RF noise/loss does, too). So in a way, extracting the third dimension is trying to extract meaningful data out of our leftover garbage. It should be entirely possible, but I suspect that this data will be even less reliable than that from a 2D solution  and I’m not entirely sure yet how reliable even that will be!
For now, I am going to stick to working out the 2D solution, because at this stage I believe 3d will need all the same solutions that 2D does, plus more  so it seems like a “progressive” path  we need to solve 2D first, and that work won’t be wasted in solving 3D, I think.
In practical terms, there’s probably a lot of functionality possible even without a 3D solution. For roomlevel occupancy, the nearestproxy will still be pretty reliable (I expect typical interfloor materials will add enough RF loss to make this easier) and combining with other sensors (PIR, mmwave etc) will probably always be an important part, even for 2D (I am using Bermuda plus PIR for my office, and it’s rudimentary, but still great).
Perhaps grouping proxies by floor (which might be akin to what you were suggesting) in order to “constrain” each floor of proxies onto separate, parallel planes would then give us a perfloor location from which we’d choose by closest distance… I don’t know. It’s certainly something I am keeping in mind, but we are a long way from being able to worry about it in a productive way.
Re AI, I’m not sure how much benefit it might provide  again we’d need someone on the other side of the DunningKruger curve to weigh in. Maybe it would be really good for tuning algorithms that clean up the distance measurements, or for realtime estimation of distances based on previously observed patterns  but maybe it’s not a good fit for any current ML patterns  I really don’t know. My gut feeling is that in these earlier stages there’s a lot to do in the basic mathematical realm of cleaning up and interpreting data, and that AI might be more useful down the road  but I could be wrong about that  maybe we could throw a sack of numbers into a GPU and it will work it all out! It would seem likely that it might be wellmatched for estimating positions within a room given that RF reflections are so insanely complicated and simple at the same time. I’d love to hear from anyone who might have relevant experience in that area.
Sorry for the long rant, but part of it is just me mulling things over in my mind and thinking out loud.
My current thinking about nextsteps that I can/will actually do are:

Beacon UUID / phone IRK/PrivateBLE matching

create perproxy distance sensors for each beacon so that I can easily use the history tool to visualise what’s happening with the data, including missing packets. The current distance and area sensors are good, but their data makes it clear that
 missing packets are causing spurious area switches
 noisy data makes it hard to choose between nearby areas that are open plan (lineofsight)
 having multiple proxies in one area really helps with both issues (graph showing (effectively) areaofnearestproxy and distancetonearestproxy over time for my watch):

experiment with some smoothing/prediction filters on those distances to fill in missed packets and reduce the noise without losing responsiveness. I’m thinking Kalman filters, or maybe just a “twoeuro” filter might be enough. Having the data easily graphable right in HA will be a good start for evaluating different methods. I like the idea that a Kalman filter gives a “predicted” result, which might be particularly useful for making a decision when a given packet is missing. I know it’s sort of a lowpass filter that’s required, but given the noise is additive rather than symmetrical and also I want to preserve responsiveness I feel that simple smoothing might be a poor fit.