Users within in a User Group not affected from approval workflow can't edit the first node of a section.

Assumption
i need to create an approval workflow to limit certain user: they can publish contents in a part of the site and only edit/create (waiting an approvation) in other parts.

I have created a Users Group “gruppo Segreteria” and a new section “Segreteria”.

This is my Contents Structure:
Home (Section: Standard)

• Subtree A (Section: Standard)
  • node a1 (Section: Standard)
  • node a2 (Section: Standard)
• Subtreee B (custom section: “sezione Segreteria”)
  • node b1 (custom section: “sezione Segreteria”)
  • node b2 (custom section: “sezione Segreteria”)

The section “sezione Segreteria” is the part of the site where users of “gruppo Segreteria” can publish contents directly.

I have 2 Workflows in Standard Workflow Group:

• one for Event / Approve
• one for Event / Update hidden field (for a postponed publication)

In the first workflow (approve) i have 2 events:

• one for Standard section (only admin or editor can publish directly, they not affected by the event)
• one for “sezione Segreteria” section (admin, editor and “gruppo Segreteria” user can publish directly, they not affected by the event)

The problem
A “gruppo Segreteria” user can:

• Edit Subtree B -> can’t publish directly, the new version waiting in my pending list
• create a new child of Subtree B -> no problem, publish content directly
• Edit an existing node (i.e. “node b1”) -> no problem, publish content directly

It seems that the first node of a section took the section ID of his parent (in this case Standard section).
With debug.ini i see this behavior for Subtree B:
Only the Standard workflow event kicks in, thus the edit going to waiting a wrong approvation:
We are going to create approval -> Defferred to cron
If I change the order of my two events in my main workflow there are 2 cycles the workflow run until the Standard section.

Suggestion from share.ez.no
it seems that the code which checks the parent node was added by Kirill Subbotin in 2005, to fix this bug: https://jira.ez.no/browse/EZP-6537

Step to reproduce
Follow the assumption