Bookkeeper doesn't really have a real NameSpace, it operates by ledgerId. I have opened and worked on https://issues.apache.org/jira/browse/BOOKKEEPER-873 which allows applications to pass-in LedgerId instead of BK client API picking one for them. But that really doesn't offer much flexibility.
Since ledgerId is a long we can't have 128-bit UUIDs as ledgerIDs and this severely restricts the range if we are generating ledgerIDs through a random generator (https://issues.apache.org/jira/browse/BOOKKEEPER-864)
Best solution for this is to offer a real name space, and I believe it is relatively simple than offering 128-bit ledgerIDs.
Analogous to regular filesystem, we treat our ledgerId as inode-number. Create a new name space in ZK with the user provided pretty-name and provide simple mapping at ZK between name-to-ledgerId. This mapping is static, and never changes once created. i.e name-x always points ledgerId-z. Given this most part of bookie code doesn't need to be aware of this mapping, and changes mostly will be confined client code and in create/delete/list paths.