What is the intended (future?) design concerning structured type (entry.payee, amount.numbers, ...)

[mlell]

There are multiple structured objects which can be accessed using an object.attribute-syntax. For example, this query yields
four columns of which the first two and the second two are exactly equal:

select payee as n1, entry.payee as n2, number as u1, position.units.number as u2 from date > 2025-11-01 

What is the rationale between this duplication. It seems like the project can't really decide whether it wants a functional interface, were we apply a large set of functions to types to get our values (like currency(units(position))) or an object-oriented interface, where we use an attribute to get properties of objects like postings.units.currency.

Currently, both syntaxes are valid in beanquery. What is the intended direction of this?

[blais]

It's just for convenience.
The original query language was sort-of evolved quickly and not holistically, it was only for beancount.