Please get the backslashes out of your head 
The backslashes are a way how MP3Tag and maybe some other tools indicate that there are multiple values for a tag (technically separated by NULL bytes in ID3).
Picard doesn’t use backslashes. The way this works in Picard is that Picard internally allows for multiple values for a tag. If you right click on a tag and select “Edit…” Picard will open the tag editor, where you can see and edit all individual values:
For display the default separator is "; ", so the above will be shown as “Wonder Woman; Batman” in the tag list.
If you want to use multi-value tags in scripting there are specific multi-value tagger script functions. The most important is probably $setmulti and maybe $getmulti. E.g. to actually set multiple values for a tag yu can use a script like this:
$setmulti(artist,Wonder Woman; Batman)
Now specifically about the artist tag: Support for actual multi value artist tag is not very great. Hence Picard by default stores the artists as a single value as credited. Picard also stores a separate tag artists (note the plural), which is a true multi-value list of all artists. Software that supports this, such as e.g. Kodi, usually use artist for display, but artists to handle showing the songs for each separate artist in the library.
If you want you can of course make the artist tag also a multi-value tag, e.g. with this script:
$setmulti(artist,%artists%)
Just be aware of the advantages and downsides. The advantage clearly is that you get separate values, and software supporting this can properly display each artist individually and show the files if you filter for that artist.
The downsides are:
- A lot of software does not support this
- You loose the ability to display the artist as credited (“Wonder Woman and Superman (feat. Batman)”).
IMHO having the artist as credited in the artist tag and have a separate artists multi-value variable is the more flexible approach, if supported by the software. But that’s just my opinion.
My general recommendation to everyone is, use ID3v2.4 unless some very specific issue forces you to use v2.3. If you try to prevent some yet unknown issue in the future which you might have with a software you don’t even know about it yet that’s basically an impossible endeavor.
It has been debated a lot whether we should finally switch Picard over to use v2.4 by default. The biggest argument against it was Windows not supporting this. But since Windows 10 actually does I think it’s time and we will switch defaults in one of the next releases (not 2.7, but maybe then 2.8).
As has been stated above the differences are not huge. And the ID3 implementations differ in details, because the specification is not always clear and major software sometimes just misused things for their own purpose.