I’m also using unique hash. Artifacts.jl use the sha1 tree hash of the directory. OhMyArtifacts.jl use sha256 hash. Depends on the type of artifact. it either hash the content of that file or perform tree hash on the directory.
The difference is that we don’t/can’t hardcode the unique hash in the TOML. Every hash is computed in runtime and store in the TOML. And the unit of Artifacts.jl is a directory, that means there could be duplicate files in two artifacts. OTOH, OhMyArtifacts.jl hash every single file in a directory, so that won’t happen (but we spend more time on tracking the usage of every single file, that’s a trade-off). So it’s more like a custom cache system than a artifact system. I use that name simply because of borrowing the idea and API from Artifacts.jl.
The purpose of build.jl is different, so won’t talk about it. For directly use the scratch space, the only difference is you have to maintain the path and existence manually, and also make sure every file is unique (if you do care about that). Imagine you have a package with 2 version, both of them are using the same scratch space. How do you know if an artifact is been used by another version or not? Can you delete them savely? What would happen if two version are generate the same file at the same time? Sure you can definately make them use two different scratch space, then now you have duplicate files. So these are the problems that OhMyArtifacts.jl try to solve.
EDIT: I just realize the package with 2 version scenario won’t work directly because they have the same uuid, I would need to make a patch 
. But you get what I mean.