Lazy val always has an accessor.
I may be mixing up private and private[this] a bit in my previous reply.
For non-lazy val, I have seen some discussion about the presence or absence of accessors when private of late: Change `private` to mean `private[this]`?
A truly private val doesn’t need a byte code level accessor in most cases (more complex cases, like nested classes may need accessors or bridges).
At the bytecode level, accessors can have the same name as the class field – the uniform access principle is at the Scala language level, not the JVM level, where fields and methods have distinct namespaces. So in some sense, your proposal already exists when there are accessors (e.g. public val) but super is still not allowed.
Accessor or not, I think accessing a super val when defining a child can be made to work if its protected or public or (maybe) in a sealed hierarchy.
I suspect this would make initialization issues more common if used heavily though – even though subclasses are initialized after their parents, there are many ways to get in trouble, and vals on traits would be problematic.
For your exmple specifically, if you “override” a val, you are really creating a new val and overriding the def accessor to redirect from the parents val to the childs while simultaneously providing the initial value. The actual val from the parent still exists in the class – at the bytecode level children can only append fields to a class, they can’t override them.