The leading colon intends to express that the master argument is an url. However, the as of the current semantics, it's a volume name directly, not geo-replication style url. Therefore the colon is a nuisance.

An implied issue is future compatibility (regarding possible future when a broader range of urls can be used for master). Ie. as of now, simple identifiers (strings with no path/url separators (like :, /, @)) are understood as sugared urls, namely <id> is desugared into file://`pwd`/<id>. With this scheme it's ambiguous whether <id> represents a sugared url or a volname. So we have to change the desugaring of <id> to a url (the current one is quite unfortunate anyways, given its dependence on user's location). There are two proposals for this:

a) Change url sugaring so that simple identifers will be interpreted as volume names (ie. <id> would mean gluster://localhost:<id>); then url/volname distinction disappears and we can drop the colon now without concerns.
b) Change url sugaring so that simple identifiera are uninterpreted as url. Then volume names and urls live in two separate namespace so we can use volumes without risking ambiguitly later on.

I'd go with b) -- accepting simple ids as urls are a special case anyway, which hurts the uniformity of the url sugaring logic. Ie. when we desugar an expression like <domain>:<subexpr> (ie. figuring out the url scheme of it), the scheme should be clearly deducible from the format of <domain> and <subexpr>. We'd like to have a rule like <domain>:<inner-url> desugars to ssh://`whoami`@<domain>:<inner-url>; and a rule like <domain>:<vol> desugars to gluster://<domain>:<vol>. If the simple identifier is meaningful as an url and as volname too, then both rules  match <domain>:<id>, having to add a special case for deciding which one to use. b) solves this problem clearly.