I asked this question before. There is no direct support of this and I already forgot the reason.
However, if you are just doing the spine on your own computer, there is a work around for sharing assets across spine project.

You can use "Link" to make clones of a directory on different locations. By doing this, when one of files get updated, it will automatically update all instances from the clones.

e.g.

• Root/Shared/<your shared images>
• Root/Project1/images/Shared/<clones>
• Root/Project2/images/Shared/<clones>

The Tool: https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html

However, there is one drawback. The links are local to your computer.
If you copy the whole folder to other computer or USB drives, it breaks and become individual copies.
You will have to setup the links again.

This is just a workaround, the ultimate goal would be having spine to support a secondary common image folder in addition to the project's own image folder. (Hi Spine Team, have this suggestion been request before?)

Ah, I see. The tool I post is just a windows GUI app to avoid touching the command line when using link. In fact, most OS including Mac support this similar feature. You can google "symlink mac" for similar solution on MacOS. If you manage to put same images in every spine project, using symlink still help reduce the work to mirror the share folder locally.

A more advance approach would be to use some file hosting that support "ignore" folder instead of Google Drive, say GitHub. You can then only sync everything including the shared folder from the root folder but mark clones in projects ignored to prevent auto sync and finally use symlink to mirror those folders.

Of course, this all is only worth to do if you have lots of projects and spine team has no plan on improving this issue in the near future. better see how official response to this first.

Spine only shows files under the Images node for the specified images folder and only watches that folder and its subfolders. Currently Spine only allows image paths to files that have a corresponding tree node under the images folder.

With a bit of effort we could allow relative paths to find image files outside of the images folder, but this would mean you'd have attachment names or paths like ../shared/head. I'm not sure that's a good idea though, since texture packing cannot give texture regions a name with a relative path like that. You would need to implement an AttachmentLoader that knows how to map such a name to the right texture atlas region.

One typical setup is to use paths like this:

shared/sword.png
skeletonA/head.png
skeletonB/head.png

Or a single skeleton with skins:

sword.png
skinA/head.png
skinB/head.png

Or multiple skeletons with skins:

shared/sword.png
skeletonA/head.png
skeletonA/skinA/body.png
skeletonA/skinB/body.png
skeletonB/head.png
skeletonB/skinA/body.png
skeletonB/skinB/body.png

There are a couple options in the tree to hide skeleton and/or skin names:

Image removed due to the lack of support for HTTPS. | Show Anyway

How about the multiple image folders suggestion?
It feels more natural to do it this way. At least those shared images will show correctly under the scanned image tree. Maybe just have multiple image trees when using multiple image folder instead of trying to put everything in one image tree to keep things clear:

Images (images)

---

<images files>

Images (shared)

---

<images files>

When compared to supporting relative path and having "../" on attachment, it feel more manageable.

That would be a pretty reasonable solution except that it can result in image file paths not being unique. If both image paths have head.png, which one should be used? Spine could just pick one arbitrarily (have to make sure the texture packer makes the same choice) and if users don't like that choice they'd need to remove files with the same relative path. With that behavior we could implement multiple image folder paths, though I do like the simplicity of a single image folder.

This feature is too large to fit in v4 but I've created an issue to track it:
https://github.com/EsotericSoftware/spine-editor/issues/577

Here is a little thought about th unique path issue,

I think it should just let user to specify the image folder to use when they manually editing the attachment path. Just like visiting a index.htm file on any website, user obviously need to tell which domain they want to load whether it is google.com or esotericsoftware.com.

In theory, user generally don't need to touch it as images are imported by default and just being dragged from the image tree to the canvas which the image folder is implicitly known when being dragged.

The image folder selection UI and image path prefix can also be hidden when not using multiple image folders. Just like how you hided the "default" skin when skin is not used in a project.

when multiple image folder NOT used:
-head.png

(the complete abs path could be "images/head.png" internally which is transparent to user)

when multiple image folder is used:
-[shared] / head.png
-[images] / head.png

where [] maybe presented as a drop down for user to change in an attachment.

For simplicity, a rule can be made to prevent image folders to have the same name.
Say default folder is called "images", additional image folder can no longer be called images.
If user want to use "c:/workspace/spine/shared/images" as secondary folder, need to rename it to something like "c:/workspace/spine/shared_images" to avoid same name issue.

The thing that could be a problem is that those entries under the skeleton tree seems always need a unique name which I quite don't understand as a programmer because all of them are unique by their full path under the tree.

Example:
root/body_part1/eye
root/body_part2/eye << this is forbidden because bone eye already exist.
but they can be identified correctly with full path...

This unique file name limitation could cause problem when multiple image folders having file with the same name.

Anyway, thanks for creating an issue for this improvement.
I would be find without this feature but I do like contribute my thought to help development goes in the right direction especially for feature that could improve my workflow so pardon me if I typed too much on this subject.