Including verification dependencies breaks imports

[HSMF]

In a setup containing nested projects, such as when including dependencies as git submodules, importing packages from that dependency is not possible.

Below is a simplified structure from including viperproject/gobra-libs:

├── main.gobra
└── pkg
    ├── math
    │   └── math.gobra
    └── util
        └── util.gobra

main.gobra

package main
//+gobra

import "pkg/math"

func client() {
	assert math.Bar() == 1
}

pkg/util/util.gobra

package util
//+gobra

ghost
decreases
pure func Foo() int {
	return 1
}

pkg/math/math.gobra

package math
//+gobra

import "util"

ghost
decreases
pure func Bar() int {
	return util.Foo()
}

---

Verifying pkg on its own works fine: Running gobra -r -I . in pkg yields no errors.

Verifying the client project, however, does not work: gobra -I . -p . yields the following error:

19:13:19.993 [thread-6] ERROR viper.gobra.reporting.FileWriterReporter - Error at: <./pkg/math/math.gobra:4:8> ./pkg/math/math.gobra:4:8:error: Explicit qualifier could not be derived (reason: 'No existing directory found for import path 'util'')
import "util"
       ^

19:13:20.000 [thread-14] ERROR viper.gobra.reporting.FileWriterReporter - Error at: <./main.gobra:3:8> ./main.gobra:3:8:error: Package contains 1 error(s): ./pkg/math/math.gobra:4:8:error: Explicit qualifier could not be derived (reason: 'No existing directory found for import path 'util'')
import "util"
       ^

import "pkg/math"
       ^

Note that changing the import in pkg/math from import "util" to import "pkg/util" is not sufficient, as this will break verification of pkg on its own.

[ArquintL]

This issue describes the current behavior of Gobra. The Go language specification is very ambiguous about what ImportPath's semantics are (see here).
I'm thus wondering what the expected behavior / the behavior of the Go compiler are.
@HSMF Does this structure stem from an existing package hierarchy that should be verified?
I tried to recreate this in Go playground but could not get it to work without using modules. For projects that consist of multiple packages, I usually resort to using Go modules. Is this not an option here?