Does this really make sense? the overwhelming primary use case of CreateTemp is for using the system global temp dor, which is usually on a different filesystem:
https://github.com/search?q=language%3Ago%20%2Fos%5C.CreateTemp%5C(%22%22%2F&type=code
vs
https://github.com/search?q=language%3Ago+%2Fos%5C.CreateTemp%5C%28%22%5B%5E%22%5D%2F&type=code

If you have an intended target file, isn't it better to name it more deterministically (so it's also easier to clean up when you crash)?

It's a bit less lobsided if you look at results for now-deprecated former name ioutil.TempFile, though granted still quite lobsided, and worse if you filter out the cases where they've hard-coded /tmp as the destination directory (please don't do that). However I'd at least hope that most users following that kind of pattern would be doing so indirectly through a high-quality library like https://github.com/google/renameio (which, granted, has its own implementation on top of os.OpenFile)

If you have an intended target file, isn't it better to name it more deterministically (so it's also easier to clean up when you crash)?

There are many situations where using a deterministic name would be unsafe, e.g. if multiple threads or processes are all writing to that file. Such conditions are, after all, why CreateTemp exists. Regardless of one's reasons for using a temporary file, it needs to be cleaned up one way or another (at least I hope creating temporary files without ever cleaning them up is uncommon) - whether that's by rename vs. delete is largely irrelevant.

Pulling out the name of the temp file isn't hard (if it were, then CreateTemp wouldn't be terribly useful). Normally I'd use something like (error handling elided)

f, _ = CreateTemp(dir, "."+name)
f.Write(content)
f.Sync()
os.Rename(f.Name(), path.Join(dir, name))

Ultimately, however, how common this specific use case for CreateTemp is it somewhat somewhat of a separate issue from whether the function is useful in general. I'd argue that if it's useful for os.CreateTemp to have that first argument for specifying the destination directory then it's useful to have a version of it available on os.Root.

I note that CreateTemp can be implemented on top of the existing os.Root API. You can pretty much just take the existing CreateTemp and replace its OpenFile call with Root.OpenFile.

So the question is whether this is a common enough operation to justify adding to the Root API. I'm fairly dubious that it is. If we can accumulate evidence of Root.CreateTemp being something many users would use, that would be justification for adding it.

That's fair enough. To be honest, in my main intended use case I'd probably wind up avoiding the Root API anyway because I'm not in a situation where I need to worry about paths escaping the root and I'd rather avoid the extra stat calls involved in checking for symlinks.