Yeah but none of the two cases create a file or folder called '/', double or more / are collapsed into one:
OK, time to slow down. In Unix, things have names. Things that are stored in file systems can be files, directories, and a few other things (soft-links, devices, FIFOs, and other crazy tuff). Everything that can be found in a file system has a string that gives the complete way to find it; that's called the path. Typical paths may be /home/ralphbsz/calendar/next_tuesday/dentist.cal, or /usr/local/bin/bash, or /dev/ttyU0. The fact that these things exist immediately implies that directories with paths /, /home, /home/ralphbsz and /home/ralphbsz/calendar and /home/ralphbsz/calendar/next_tuesday also exist. By construction, these paths have to be unique: At any given time, there is only one thing at each path, so the mapping from path to objet is unique. The opposite is not true: The same object may be visible at two path names (due to soft- and hard-links).
Every object in the file system also has a name, which is the last component of the path name. That name is called the "filename" of the object. So for example, my dentist appointment is in a file that has filename dentist.cal, which in turn is in a directory with filename next_tuesday, and so on. Filenames are completely not unique system wide: I bet my wife and son also have a file named dentist.cal somewhere in their directory hierarchy, but unique within a directory (there are some VERY bizarre exceptions with non-unique file names that involve Unicode character translation).
So, the complete path of an object is nothing but the concatenation of all the filenames of the directories the object is in, plus filename of the object itself, and the concatenated objects are separated by "/". Conversely, the filenames are nothing but the components of the path, if you split it at "/" characters. Implicit in the path is the root directory, which doesn't really have a name (it is zero length), and that can always (and only!) be found at the path "/". This would be a good place to talk about the difference between absolute and relative paths, but I'm too lazy.
There can never be the "/" character in any filename, by construction: that character is the separated between filenames. As I said above, if you try to create "a/b", that's not a filename "ah slash bee", but the filename "a" in the directory "b". By convention, it's legal to add too many slash characters: the two paths "a/b" and "a////b" mean exactly the same thing. This is to make it easier to construct path strings by concatenating substrings: You can for example take "/home/ralphbsz/" and "/calendar/" and "/next_tuesday/dentist.cal" and just shove them together, and it will work.
Anecdote: As I hinted at above, I once (with a colleague) for fun created a file system where files DID contain slashes in their name, and where the creat() system call was capable of creating a file named "a/b". It caused lots of very funny crashes, and misunderstandings. The other fun thing to do is to implement file systems that do Unicode translation. Say for example you have a single directory containing three files, called "à", "á" and "ä" (lowercase a with backward accent, same with forward accent, same with two dots), but you're rendering it in an environment where users can't display anything other than US-ASCII. When you do an "ls", the user will see three files, all just called "a". That will make the user's head hurt. When they try to open the file called "a", should they get one of the three, or should we refuse because it doesn't exist? Either way, the user will be angry. And if they try to create file "a", should we refuse to do that (it's unsafe because ls showed three files called "a" already), or should we let them do it? Much fun, but fortunately, this problem doesn't exist in most real-world situations.