Values only as local variables, instead of class variables in the contents. (or also: dealing with collections)
The following problem/requirement: Task is to create an object wrapper using a binary. Let's take as an example one of the supplied examples, for example the file [java_class.ksy](https://github.com/kaitai-io/kaitai_struct_formats/blob/9a38c7d4c5058f7302e0a3272adfde78f6e62a07/executable/java_class.ksy). This file is relatively complex in structure and consists of some repeated elements. In order to know that this is a repetition, a "number" is required in the file. This "number" is for me in the object model in a certain way but relatively irrelevant. It even confuses in part, because the block that is repeatedly mapped as an object construct, since it is a collection of a subtype or an array. The number of objects is not in this object, but in the object above it. This means that I don't really need this "number" in the object above. Even if the serialization is available at a later time, then I would have to keep this "number" synchronized with the "collection". In the object-oriented world, however, this is of course a no-go because the collection itself knows how many elements it has or how long it will be. This is of course completely different per programming language, but in principle it is in a way comparable.

If we look at the file java_class.ksy again, for example, we see that we have several "number" elements here. In other words, you could reduce the result if you did not have this problem. 

```yaml
  - id: constant_pool_count
    type: u2
  - id: constant_pool
    type: constant_pool_entry
    repeat: expr
    repeat-expr: constant_pool_count - 1
```

I would therefore like to ask the general question whether there will be changes in the future, or whether certain elements will be read but not made available to the class as an independent property.

What I would still see as a possible solution would be to provide a kind of separate subspecies "Collection" for repeated elements. This is based on a count and contains a child type, which is repeated X-times. The collection would have a managed property "number", which would depend on the contained elements. This would also solve this problem in the subsequent serialization process. Sooner or later, there'd have to be a lion in here anyway.