The answer to this is to use Salesforce DX, which will be released any day now. DX allows you to create new dev orgs that all share the same namespace as the packaging org. This makes it a lot easier to deal with the namespace, since all orgs you develop and test in will have the correct namespace.
If you don't want to move DX, your next best choice is to develop exclusively only in non-namespaced dev orgs, and use a code versioning system to deploy code from the developer orgs to the packaging org. In other words, never develop in the packaging org, and only dev orgs.
Q: What about Formulas
Write the formulas in your non-namespaced orgs, and do not use the namespace in any of your formulas. They should be properly fixed up when deploying to your packaging org when you deploy to it.
Q: Is there are any easy way of doing development in multiple dev orgs with namespace in mind?
Preferably, use DX. DX will be available any day now. If you can't or won't use DX, you can do this using normal dev orgs, but it requires some strict development practices.
For example, instead of new PageReference('/apex/mypage') in Apex Code, you must use Page.myPage instead. For @RemoteAction, use {!$RemoteAction.className.methodName} instead of className.methodName. And so on, and so forth. Use only namespace-aware functions instead of non-standard "hacks."
Q: Is it possible to achieve something similar now?
Yes, it is possible. However, you must strictly avoid using anything that will break. This means doing your research on what works and what's broken, and avoiding what's broken. For example, inline queries are generally safe without the namespace, as are most class, field, and object references, etc. It just requires more work and more diligence than it would take for a non-namespaced package.
This should be possible with Second Generation Packaging. You can specify the dependencies of a package in the sfdx-project.json file.
In case you prefer to install the package in a script, you could do it like this:
#login to your DevHub
sfdx force:auth:jwt:grant --clientid [consumerKey] --username [devHubUserName] --jwtkeyfile assets/server.key --setdefaultdevhubusername
#create scratch
sfdx force:org:create -v [devHubUserName] -s -f [config/project-scratch-def.json] -a [scratchOrgName]
#push source to scratch
sfdx force:source:push -u [scratchOrgName]
#install package
sfdx force:package:install -i [packageId] -w 30 -u [scratchOrgName]
Best Answer
You specify the namespace in the scratch-org's configuration file when using the org creation command. You must first associate the packaging org with your Environment Hub Org before you can use the namespace parameter, and the namespace must match the namespace prefix in the packaging org. I can't share specific details, but the answer is, yes, you will be able to use namespaces in your scratch orgs, which will ease spinning up new orgs and deploying changes to your packaging org.