Too complex for my small brain

You mean the code in production? That's not “my” code, just code I helped to develop. And I would need to spend a lot of time what dependencies we are tracking, how and why (it wasn't about lock tracking, rules there were different, that's why simple pair of before and after traits were not enough).

I think it would be better to concentrate on that simplified example that started the whole discussion.

I kinda assumed that it would be trivial to follow yet, apparently, it's not trivial… thus I would try to explain the ingredients that are used there and show how can they be combined together to detect violations of locking ordering.

1. Zero-sized types, in Rust, may carry compile-time payload. Specifically:
   1. They can carry information about some other type
   2. They can carry information about lifetime
   3. They can carry values (integers or sequences of integers)
2. To check the correctness of locking we would use all three properties. Specifically:
   1. We would be putting information about all currently taken locks in the context (by using 1.1 property, obviously)
   2. We would do that by putting zero-sized reference to the previous context: if you take &'a mut T and convert into PhantomData<&'a mut T> then this zero-sized type acts precisely like a real reference… except you couldn't use it to derefence anything (but we don't have anything interesting in the context itself, the only interesting things are in the context type, thus we don't need to dereference anything) – in particular as long as PhantomData<&'a mut T> exists the original context is not accesible (by using 1.2, obviously)
   3. And we also would add some constant to know what we have put in the that context, e.g. we may put all locks in one enum and then simply use LockPriority::IPV6LOCK us usize (by using 1.3, obvious)
3. And with all that placed in our context we only just need to verify that lock that we are taking right now is valid. In Rust 1.79+ that's trivial: you just used const { assert!(…) } or const { if … { panic!("…") } and that's it. That's a bit strange because it looks as if that's a runtime check, but no, that's compiler-time check. So… you have two constants, compare and you would know if lock is Ok to take or not (ask me if you need to backport it to older versions of Rust, there you needed somewhat more complicated dance, but it's also doable).
   Note that you have access to all types in the chain here, even if indirect, and could implement arbitrarily complex verification scheme… it's only hindered by the fact that const functions couldn't be part of the trait, so you would probably want to put your machinery in separate module to not fill the namespace with helper functions.

And that's… essentially it. We are done. Just need some syntax sugar to make it more pretty. I guess you would want to add something like LockPriority trait:

pub trait LockPriority : sealed::LockPriority {
    const PRIORITY: usize;
}

impl<'a, T: ?Sized, const P: usize> LockPriority
for TakenLockPriority<'a, T, P> {
    const PRIORITY: usize = P;
}

mod sealed {
    pub trait LockPriority {}
    impl<'a, T: ?Sized, const P: usize> LockPriority
    for super::TakenLockPriority<'a, T, P> {}
}

Would also need some macro because you would be doing things like
let (mut ctx, guard) = mutex.lock(UsePriority(& mut ctx));
pretty often. Or maybe not, maybe it's better to keep that explicit. Attempts to use wrong context would be detected and stopped by the compiler, anyway.

P.S. The while thing relies on the fact that correctness checking for the const expression and detection of errors happens not when you define some generic function, but when it's instantiated. And it's obvious why it have to happen like this: correctness checking of something likes const { assert!(…); } couldn't happen during definition time because what goes into assert!(…); may define on constants that ass passed as arguments. And doing that in runtime wouldn't make any sense: this would mean that your constant value would, suddenly, depend on something in runtime…