Plan 9’s mk isn’t really a radical departure from Make, it is more of an adaptation of it to the (decidedly non-POSIX) Plan 9 shell, rc, with modest extensions. One design mistake in make that mk fixes is variables in recipes: those are now passed as environment variables, with no prior substitution, so no more writing $$$$ to get the current PID in a recipe (and it’s written $pid in rc anyway).
Unfortunately, mk inherits from rc the principle of having the list of strings as the fundamental datatype (also used by Jam). That works, but it’s noticeably more limiting than Tcl’s route of having everything be strings but with robust quoting and unquoting procedures for putting lists inside them—at which point Tcl starts to look like a Lisp-2 with a slight propensity for stringiness and a mildly unusual syntax.
Actually it doesn't really solve the $$foo problem. If your make target has an inline shell script with a variable reference, is it referring to a make variable or a shell variable? Is it set in make? If not, what will make do with that variable reference in the inline shell - nothing? Make it an empty string? Keep the literal '$foo' string? And what if both make and inline script have the variable set but they need to be different?
It does solve the $$foo problem in that mk just doesn’t do any variable substitution in recipes, at all. For each invocation of a recipe, it adds the values of mk variables it has computed to the parent environment, then execs a shell and passes it the entire recipe verbatim.
I've been seeing people, never ones who were actually there, make this claim in the last five to ten years. Rc was on tenth edition Unix. I've seen no evidence that it originated on Unix. The manual calls it the Plan 9 shell.
So rc was made for Plan 9. The examples in that paper are definitely on tenth edition Unix, I think this would be because
A fairly complete version of Plan 9 was built in 1987 and 1988, but development was abandoned. In May of 1989 work was begun on a completely new system
Unfortunately, mk inherits from rc the principle of having the list of strings as the fundamental datatype (also used by Jam). That works, but it’s noticeably more limiting than Tcl’s route of having everything be strings but with robust quoting and unquoting procedures for putting lists inside them—at which point Tcl starts to look like a Lisp-2 with a slight propensity for stringiness and a mildly unusual syntax.