This is largely resolved now - turns out my code sucked rather than needing to do something clever with Guix module importing, which is what I suspected ;-)
The only compromise I'm making now is that any complicated manifest for example, I am having to split into a trivial manifest script calling into a library that I can then unit test - so it's not quite as good as having a meta switch for manifests or repl scripts, but it's good enough.
I have a theory about what is causing this - I think it's me not thinking about deferred evaluation carefully enough.
This is true, but my second post was still missing the point!
What I think is happening is that the propagated-inputs in my newly created test-package will have their evaluation delayed until the build occurs in the daemon. I presume at this point my local library I've used add-to-load-path to include in the manifest will no longer be accessible and hence the eval failure being returned.
The problem was actually much easier to solve than I had originally over-thought - simply by making my-package- with-my-gurobi a procedure which returns the package rather than having it defined as a variable that contains a package all the problems go away apart from a handful of imports required in the library script. The my-gurobi-package can also be nested inside the let statement, and the whole procedure added to the library.
(define (my-package-with-my-gurobi)
(let* ((test-package-string (get-env-var-or-prompt "GUIX_TEST_PACKAGE"))
(test-package (specification->package test-package-string))
(my-gurobi-package ((transform) (specification->package "gurobipy"))))
(format #t "~%Setting Test Package: ~a~%" test-package-string)
(package/inherit test-package
(propagated-inputs
`(("gurobipy" ,my-gurobi-package) ;; add my new gurobi
,@(alist-delete "gurobipy" (package-propagated-inputs test-package))))))) ;; remove the original gurobi and splice