Thanks for digging into this Ravi, and especially the reminder to look closely at the proposed associated semantics.
Right, I guess it even means "should be disabled in shipping code"; which is how I read the "meant to" in the Debug level semantics:
Messages meant to be useful only during development. This is meant to be disabled in shipping code.
This sounds good and matches what I had thought of as Trace. It is hard sometimes to re-associate a words meaning in one's head... so I had still in my head the meaning of Debug I've been used to.
I think it all works out in the end thanks to an level/severity between Info and Warning: the Notice level. We did not have anything between Info and Warning the current logging proposal (which was modeled after slf4j and similar ones).
This has API impact so we need to decide if we allow this or not, so let's make sure we counciously pick what we want here:
Since Level is nicely modeled as an enumeration such "levels specific to backend" means we'd require being able to represent them as "custom" Level which was initially decided against in the SSWG Logging thread. This can be considered again, but should be a conscious decision that we do allow these.
If we want to allow such "specific to platform/backend/anything" log levels then the enum Level would have to be gain case custom(Int) (requiring that int to be > 7). Otherwise in the user facing APIs (.log(level:message:...)) there would not be a way to pass in a different value. It has some "abuse potential" technically speaking... Though it could be seen as an escape hatch, and if an "unknown level" is seen by any LogHandler it would flatten it down to Debug anyway for example. No strong opinion here to be honest, just wanting to make sure we specifically allow or disallow this (with current proposal being on the disallowing side).
Summing up: For my, and the general "library which wants to log a lot of debug info" use cases, I think the above proposed semantics can work. 
With the proposed semantics what people may be used to as "trace" from e.g. Java logging ecosystems here would be "debug." The trace question though may have become an "do we allow custom" which was discussed a bit already and decided against in the logging proposal.
"Very verbose logging" can be then Debug, and things to look at during normal operations can be split up between Info and Notice.