Haskell record fields get turned into top-level functions that act as field accessors. That is, if we have a record:
data Student = Student { name :: Text, school :: School }
we end up with two functions 'name' and 'school' in scope that extract the values of their respective fields:
name :: Student -> Text
school :: Student -> School
This means it is common for field names to be composed with functions. I write code like this all the time:
schools = map (schoolId . school) students
This is compounded by the fact that a lot of newtypes use record syntax to define functions in this style that are even named like functions:
newtype Reader r a = Reader { runReader :: r -> a }
Importing runReader from a module, you might not even know that it's implemented as a record field! This is pretty handy since you can change the implementation of runReader from being a record field to a normal function without breaking most of your callers. (In fact, I think this might have happened with runReader being implemented in terms of runReaderT.)
This kind of pattern means that people write lots of code that uses record fields as functions, sometimes without even realizing that they are using a record field!
The practical upshot is that myRecord . someField is used with . as function composition all the time, so any proposal that cares about backwards compatibility can't change the meaning of . in that context.
Rereading now, it seems you're asking how interpreting a . b as record access only if b is a record field in scope would break existing code.
The new record system is implemented on top of a HasField typeclass under the hood. Thanks to the way Haskell's typeclasses work, this means that the instances that define what fields a record has will be in scope when you import the module containing that record—directly or indirectly—even if you don't import the record itself.
This means that even if we do not have a record with a field b in scope, we might still have the instance for some other record in scope—leading to ambiguity in previously unambiguous code. Moreover, even if a . b is unambiguous right now, a record with a field called b might be added somewhere deep in the codebase and cause unexpected ambiguities in the future.
I suppose you could say that a . b is composition whenever a function b is in scope, even if there is also a record with a field called b. That rule would not break existing code, but it also seems inconsistent and confusing—a.b and a . b are sometimes the same and sometimes different, depending entirely on whether b is in scope.
Making the meaning of . purely lexical rather than depending on what's in scope seems a lot more consistent and easier to follow. It's already the case with Haskell anyway, since . can mean function composition or a qualified name depending on the spaces around it. This isn't an ideal situation, but I don't think we can aim for "ideal" in a living language that's 30 years old.
This kind of pattern means that people write lots of code that uses record fields as functions, sometimes without even realizing that they are using a record field!
The practical upshot is that myRecord . someField is used with . as function composition all the time, so any proposal that cares about backwards compatibility can't change the meaning of . in that context.