Nested dub invocations behaves randomly

[Geod24]

I have the following in my dub.json file:

{
    "preGenerateCommands": [ "$DUB source/scpp/build.d" ],
}

Permalink: https://github.com/bpfkorea/agora/blob/952cd01b14778d5ca5e34c049c8217c59037614f/dub.json#L14

This calls a build file that builds a C++ library. The build file itself doesn't use any of dub's features, it's only here to be cross platform (because rdmd wasn't working well for a reason I forgot).
This is literally the package definition of the build.d file:

#!/usr/bin/env dub
/+
 dub.json:
 {
     "name": "cpp_build"
 }
 +/

Permalink: https://github.com/bpfkorea/agora/blob/952cd01b14778d5ca5e34c049c8217c59037614f/source/scpp/build.d#L1-L7

I put a -v in my $DUB invocation just to see what happens, and lo and behold found a few issues.
This is the flags I see when the compiler is invoked:

$ ldc2 -extern-std=c++14 -preview=in -extern-std=c++14 -c -ofsource/scpp/.dub/build/application-$DFLAGS-posix.osx.darwin-x86_64-ldc_2093-CEAA0795D0F4AF6821A572E766E19528/cpp_build.o -w -oq -od=.dub/obj -d-version=Have_cpp_build source/scpp/build.d -vcolumns
Linking...
ldc2 -ofsource/scpp/.dub/build/application-$DFLAGS-posix.osx.darwin-x86_64-ldc_2093-CEAA0795D0F4AF6821A572E766E19528/cpp_build source/scpp/.dub/build/application-$DFLAGS-posix.osx.darwin-x86_64-ldc_2093-CEAA0795D0F4AF6821A572E766E19528/cpp_build.o

My original call, in the parent package, was dub test --compiler=dmd. dub points to the one distributed with dmd-2.094.0-beta.1, through the install script. So by default this bug should select dmd, right ?

Issue 1: ldc2 is used. Because my dub.settings.json uses ldc2 as default compiler. Obviously I override this with --compiler, but the nested one doesn't pick it up. That might be a sensible behavior, but it's a very surprising one. Conversely, if I had no dub.settings.json, dub would always use dmd regardless of what --compiler I provide.
Issue 2: What are those -extern-std=c++14 -preview=in -extern-std=c++14 flags ? The duplication is a tiny thing in the package and can be ignored. But the problem is that the parent package exports the flags as DFLAGS, which always forces the inner invocation to pick it up. That's especially problematic because not everything is propagated. The compiler, for starter, and perhaps the LFLAGS.
Issue 3: To add to the inconsistency, the root path dub seems to use is source/scpp (where the file lives), according to where the object is built. That's a behavior I think is sane, however it contradicts what dub does with the local dub.settings.json.

In short, I think dub some/single/file.d should behave as dub --root some/single/ --single path.d and the parent dflags shouldn't propagate to the child.

[Geod24]

This has been fixed by @omerfirmak in #2047 and #2048 . The issue with dub.settings.json is minor and not really a blocker, so closing this.