I just want to mention a current behavior that works in linux that might be something to consider when running 2 instances of the terminal application (i.e. cli).
Running 2 instances of the cli with the default profile doesn't work because the instances are sharing a /tmp directory. Upon sync the contents in /tmp changes and thus causes the files therein to be lost. This causes any external editor's file contents to be decoupled with the database representation (by id).
The work around that I've found is to create a second profile folder and create soft links for the keymap.json file and the resources directory within the second profile back to the first.
The second profile looks like this:
Joplin-2ndprofile
├── database.sqlite
├── keymap.json -> ../joplin/keymap.json
├── log-database.txt
├── log.txt
├── resources -> ../joplin/resources
└── tmp
Then running a second cli instance is straightforward: joplin --profile joplin-2ndprofile
I do not recommend linking the databases as that could be problematic in the future. Although it does work fine for now -again just don't do it without having clear development rules in place about database vs application instance behavior.
Also, FYI, soft linking the <profile>/resources directory from a joplin-desktop profile does seem to work but I haven't tested it very much.
In addition, I'd like to point out that while linking the <profile>/resources seems to work fine for cli and desktop apps. I'm weary of the practice without some dedication to this concept being a -feature- and not just a -hack-.
At any rate, by linking the <profile>/resources directories we save transfer back and fourth to your sync directory if you are using nextcloud, et. al.
[edit]: as a side note -it's probably obvious but do consider that editing the same note in multiple instances is not handled in the behavior outlined here. Therefore, editing the same file between multiple instances of Joplin at the same time is bound to create conflicts -hence, it's a bad idea 