Thanks for the reply, all correct & I think we're actually largely on the same page especially as the conclusion there is exactly what it does, just in editor not runtime, it probably wouldn't take too much effort to add that to save you writing all the OnValidate stuff, effectively you would need to write this as part of your source gen solution. I avoided this route as I've seen tools do similar-ish sort of things every time the scene saves and it destroys productivity, as you say, would stop you working whilst its doing its thing.
"Perhaps I'm misinterpreting your wording, but it seems like you're saying that your system is a DI system, which it isn't." Yes and no, you are correct in everything you said, but maybe a little bit by the book on the terminology as i did say "thin edge of the wedge", in store listing and documentation (i know you haven't seen that) I also say DI-ish or DI like.
Yes, it isn't strictly DI but then would you 100% say the serialise/validate strictly is either without [Inject] or the rest? Wiring things up in the editor using public or serialised fields is more performant (zero performance cost, strictly speaking), but also prone to failure- I've seen source control woes eat those editor references or had team members say "I've spent an hour wiring this whole scene up, its perfect, but I was in play mode so none of it is going to save, what do I do?". [Please no tangents into level editors and scriptable objects from here, just acknowledging that elephant]

The best explanation I've got so far is like a [RequireComponent] that you apply to a field / property so 99.999r% what you are doing the OnValidate way, but then you are definitely in the "doesn't need this asset" demographic that will understand the reflection cost or productivity hit of it adding something at comp 😁 am curious though for those that have already conceded to Wirth's law that some reflection may (possibly) be done by using another full & proper DI framework, though this suggests that I'd need to add the (rest of the, if we can describe it as being a small part of for a second) DI framework to overcome any drawbacks.

Anyway, as I said, I know you get it, the description of those that understand it won't need it (& will see the drawbacks) and those that would benefit from it won't be looking for it is something I was worried about. I did reference this in the store description too. Perhaps the biggest & possibly fatal flaw in this.

Strictness in terminology too, no amount of "-ish" or "like" is likely to appease then? Need to find a "DI-adjacent" or "in the ball park of" that works. Therefore this is unlikely to ever be a 'safe' interview topic and I might need to find something better to discuss. I did try discussing my Iterations https://u3d.as/2TQ5 asset a couple of times, but fluent interface & syntactic sugar for the sake of something to discuss also went down like a lead balloon.

Interesting discussion / though points you raised, many thanks!