I have to deal with a document that has an unfortunate vague structure
which involves unnumbered headlines spanning a couple of numbered
ones. I'd like to convert the document into Org and thus effectively
need to implement a feature that would allow unnumbered property in Org
not to be inherited by children of unnumbered items in some cases.

Say, in the following toy example

#+BEGIN_SRC org
* section-one-title
blah
* the first two prime-numbered sections (duh)
:properties:
:ignore-this-outline-level: t
:unnumbered: t
:end:
** section-two-title
blah
** section-three-title
blah
* section-four-title
blah
#+END_SRC

section-three and section-four would be treated as being on the same
level as other section-x's, their children treated correspondingly.

For exporting needs, I chose to format the unnumbered headline the
same style as section-x's, only unnumbered, and have section-two and
section-three be numbered as if the unnumbered headline didn't
exist.

First,
I need to mark (?) parts of the parse tree that are children of
the unnumbered item, and are not explicitly marked unnumbered
themselves, as exportable when being passed to
org-export--collect-headline-numbering.

This is where I ask for help, as it's not clear to me how to do that.
My hypothesis so far was that org-export--prune-tree from ox.el filters
out unnumbered items but my attempts with debug-on-entry did not confirm
this. Could someone help?

Re: (?) maybe children are never marked as exportable in the first place
and the tree just does not get traversd too deep. Again, I don't yet see
which function is to be patched to let them through.

Second,
I will also need to redefine specialized functions like
org-html-section, turning
org-export-get-headline-number
into
org-export-get-deepest-numbered-parent-headline-number
and so on, but this doesn't seem to be difficult. However, if I'm
missing something and you think this could be a valuable feature, you
are welcome to share your thoughts. I'm not an experienced programmer
but hopefully I can implement this and contribute.
n(Will sign anything FSF if needed.)

I admit that the whole idea to add this to Org is questionable, and
documents structured like this better be restructured altogether. It is
likely that exported versions for some backends are not going to be
structured properly. (As far as I can see, Texinfo looks particularly
unpromising.)

Nevertheless, it is possible to at least make exported versions /look/
ok and describe possible backend-related caveats in the documentation.
I find it reasonable to keep org files structured properly, while
considering exported versions to be more of an eye candy. In my case,
the document in question is an archive entry which cannot be changed
retrospectively but me and my colleagues could still benefit from it
being tidily marked up.