What is the parent-descendant relationship in PageObjects (v1.7.x)

[RezhaBlue]

Hi all
I would like some clarification about the documentaiton for Nightwatch 1.7.x:
https://v17.nightwatchjs.org/guide/working-with-page-objects/defining-sections.html
Specifically, "Provide element-level nesting so that any element defined within a section is a descendant of its parent section in the DOM"

Question
If I create a section and include sub sections, how are the subsections locations interpreted?

For example:
if the section named "database" with locator in css is table
has subsection "entry" locator in css is thead
then will Nightwatch use table thead (general descendant) or table>thead (direct descendant)
when I do for example database.assert.visible(entry); ?
I am guessing it treats it as a general descendant, is there a way to force it to be direct if that is the case?
Furthermore, does this treat xpath similarly?

I've added a code example below for reference:

module.exports = {
  sections: {
    database: {
      selector: 'table.table-body-striped',
      sections: {
        entry: {
          selector: 'thead',
        },
      },
    },
  },
}

[RezhaBlue]

Ok an update for anyone else that passes through. Sections are very misleading.
The only time there is any path inheritance is when a top level section object has a nested elements object. In that situation the pathing is section selector + element selector.
In every other case, whether it is a top level element, top level section, or nested sections, or nested sections with element, the object should have its own distinct pathing in regards to the whole damn, Nightwatch will not use relevant pathing. This is true in 1.7.x and thus far into 2.1.6

[gravityvi]

Thank you @RezhaBlue. We will try to cover this in the documentation.

[gravityvi]

I think we support nested sections. Can you raise an issue with an example if it is not working?

[RezhaBlue]

Thank you for your reply.
If nested sections are supposed to be supported that was definitely not working in 2.1.6. We refactored most of our company code to flatten structures to avoid sections-in-sections due to this issue.
Refactoring had the added side effects of making the code easier to read, debug and maintain due to the less complex structures and reduction in verbosity so I don't know if we will go back to using nested sections if they are fixed.
For other users utility, I will try to test this again in 2.1.7 and if it doesn't work I will raise an issue.
Thanks again!