The following patch for solenv makes the problem more visible.

The logfile after the patch is generated with the patch applied and this command:
$ build -- -vr -P3 > sysui_multi.log 2>&1

Created attachment 34099 [details]
Patch for solenv to show the problem

Created attachment 34100 [details]
Logfile generated with previous patch applied.

In rules.mk there should be "date;echo done" started after generating the *.dprc,
but as you can see in the logfile the output never reaches the logfile. The
target seems never to finish.

If you force the APPxTARGET to need a little longer by increasing the number of
seconds in
	echo "in APP1TARGET - waiting a little";sleep 1
the module finishes successfull.

@ause: This might well be a dmake problem but you are the master of the *.dp*
magic files, can you have a look. It also looks strange that soquickstart.dprc
is generated twice and unfortunately dmake finishes its ?main?-target right
after the second
  /bin/rm -f ../../../../wntmsci10.pro/misc/soquickstart.dprc.

Created attachment 34119 [details]
Patch for dmake that shows orphaned child processes

This issue looks like issue 54938, but the testcase (misc-5) from that issue
still passes.

I got a short testcase:

- - - include.mk - - -
SHELL*:=/bin/sh 
SHELLFLAGS*:=-ce

TARGET=mytarget

%.dpcc : %.cpp
	@echo making: $@
	@sleep 2
	@echo still making: $@
	@+echo $@ : $(@:b).obj > $@

%.obj : %.cpp
	@echo making: $@
	@+sleep 1 # need to change .obj timestamp
	@+cat $< > $@

%.exe : %.obj
	@echo making: $@
	@+cat $< > $@

.INCLUDE : $(TARGET).dpcc

ALL : $(TARGET).dpcc $(TARGET).exe
- - - include.mk - - -

When you start it like this you get the following output:

$ rm -f mytarget.{dpcc,obj,exe} ; dmake/dmake.exe -r -P2 -f include.mk ALL
making: mytarget.dpcc
still making: mytarget.dpcc
making: mytarget.obj
making: mytarget.dpcc
making: mytarget.exe
dmake:  Warning: -- Found running target [mytarget.dpcc], finishing ...

still making: mytarget.dpcc

This output was from dmake43p01 with the lost_child.diff patch. Without that
patch the "still making ..." part would just be missing.

Even shorter:

- - - include_2.mk - - -
SHELL*:=/bin/sh 
SHELLFLAGS*:=-ce

TARGET=mytarget

%.dpcc : %.cpp
	@echo making: $@
	@sleep 2
	@echo still making: $@
	@+echo $@ : $(@:b).obj > $@

%.obj : %.cpp
	@echo making: $@
	@+sleep 1 # need to change .obj timestamp
	@+cat $< > $@

.INCLUDE : $(TARGET).dpcc

$(TARGET).dpcc :
- - - include_2.mk - - -

$ rm -f mytarget.{dpcc,obj} ; dmake/dmake.exe -r -P2 -f include_2.mk
making: mytarget.dpcc
still making: mytarget.dpcc
dmake:  Warning: -- Found running target [mytarget.obj], finishing ...

making: mytarget.obj

It looks like mytarget.dpcc doesn't get fully build because was already build
as a prerequisite for the .INCLUDE.

Created attachment 34170 [details]
Patch for dmake

The previous patch forces dmake not to think that a target is already build if
the prerequisits or recipe lines change. This can be the case for infered
.INCLUDE files.

(Issue added to CWS dmake43p01)

See issue 62118 for another (better?) place to fix the F_MADE/F_STAT flags.
F_VISITED has to be handled from that issue anyway.

I changed the summary to reflect the actual problem. The following makefile
illustrates it:

--- inc_target.mk ---
SHELL*:=/bin/sh 
SHELLFLAGS*:=-ce

%.dpcc :
# The following line adds a dependency to %.obj when the %.dpcc is included
	@+echo $@ : $(@:b).obj > $@

# This has to be build if mytarget.dpcc is included and is requested
# as a target
# Adding the wait makes sure that the unpatched dmake is ended before the
# next recipe line is started, therefore loosing it.
%.obj :
	@sleep 1
	@echo making: $@

.INCLUDE : mytarget.dpcc

# Make this the main target
mytarget.dpcc :

--- inc_target.mk ---
$ dmake -r -P2 -f inc_target.mk

If a dependency is added to a target after it is already build as an
indered .INCLUDE makefile the new dependency can be lost in parallel
builds. In this example
  making: mytarget.obj
is only issued if no parallel builds, i.e. -P1 is used.

Note, this is not an artificial example, the dependency generation stuff uses
constructs like this.

@cmc: Might be relevant for your parallel builds too.

Created attachment 34539 [details]
Updated patch for dmake/rulparse.c

I committed the patch and a testcase to dmake43p01.

@ause: Please verify.

.

.