> Okay, so what negative effect does this flattened traversal of records cause?

Well, let us describe that with a very concrete example. Let us suppose you are writing a very simple library for generic binary search trees. You will likely describe the structure of your trees with the following data types, where *T* is the type of elements that you store in the tree:
```
BTree<T> ::=
    node(1:BTree<T> 2:<T> 3:BTree<T>)
  | leaf
```
Now, with this structure, and the flattening traversal of records, it is dead easy to write a function that returns the elements of the tree in-order (aka sorted), right?
```
fun {BTreeSortedElems Tree}
   [V suchthat F#V of Tree]
end
```
Now, I'm using your library with trees containing integers, and I'm just fine. The function `BTreeSortedElems` will detect that integers are not records and hence are the "leafs" of the structure to be iterated over in the flattening traversal.

But then, if I use your library to store *strings*, which are actually lists hence records themselves. Now suddenly the function `BTreeSortedElems` will not return the various strings in my tree, but rather all the individual code points of all the strings in the tree. *Your* function has destructured *my* data structure which as the string! How bad can that be?
Of course, the same reasoning applies to any data type of my own that has at least one representation which is any kind of record, i.e., almost *any* data structure that an Oz user is going to write!

*That* is the problem with flattening record traversal.