It sounds like you are leaving tried and tested simple advancements in programming on the table just to avoid a superficial comparison.
Even then what C++ people want from a competitor is simplicity. Not to give up the essentials but to keep the crucial aspects that they can never give up and are the reason they put up with all of the complexity of C++.
I think when people want C semantics they will just use C in general, but if there is something that solves these extreme pain points in a simple way it might be enough to get someone to switch.
There are other contexts for managing mutex locks so they auto close and you could dream up one for database connections and transactions too.
The nice things about a context is you can always see it's there, destructors by design are a bit hidden which can make code harder to reason about.
I have never heard anyone say they are hard to reason about, especially if there is no garbage collection or inheritance.
For scoping files, sockets and so on, there's actually a simple mechanism in C3 that allows creating code like that very easily using macros with "trailing body". Which is a little like trailing closures in Swift, but here there is no closure, just a macro.
There is an example here: https://c3-lang.org/generic-programming/macros/#trailing-blo... but it's used in the stdlib quite a lot.
How much have you used that? C has that and it will get cleared at the end of a scope too, but it is pretty exotic because it is so fragile. It's a catch-22, if something is so big that you need to allocate the exact size to save stack space, then it could become problematic and blow the stack. This is not a substitute for having allocations be freed at the end of a scope.
For scoping files, sockets and so on, there's actually a simple mechanism in C3 that allows creating code like that very easily using macros with "trailing body". Which is a little like trailing closures in Swift, but here there is no closure, just a macro.
I think stuff like this is interesting, but it's interesting in the context of straight C, not in the context of a new language where it could be done better.
In regular C you could already create a custom allocator and macros that would use the fact that a for loop will run something after the scope finishes to mimic some of these effects.
C's syntax may be a little funky, but it's real pain point is the actual semantics that will bite people over and over until they move on.
The trailing body macro is something I think you should try out before dismissing it. It's similar to how Ruby can do it, with the closures exiting the "outer scope", which is unusual.
I'm not dismissing the trailing body macro approach, I just don't see what advantage it has over destructors which is a well worn solution. It seems like some of the design decisions are based off of 'don't do something that C++ does'
It is similar to the function stack, but push and pop can be arbitrarily granular, as opposed to only happening at entry/exit.