Ok, the initial results of my suggested approach for Module Development (start with WSP & deploy with WAP) are out. They are both good as well as sad news.
There are several important points worth noting:
1) There is no need to attach to asp worker process while working in WAP project. Setting a breakpoint would take you there straight-away.
2) Although VS does not lock neither code-behinds, not other class files. But you can not use a modify and continue approach for any of them (you cannot use this approach for class files even in WSP). Tis is because the WAP project compiles & it sdll gets copied into the site's bin folder. So, when you make a change when the site is running, VS complains that the source file has changed, and ignores the changes. You need to stop the run, recompile & rerun for any chnage (even in code-behinds) to take effect, unlike WSP appraoch where code-behinds can be changed dynamically, making it definitely a better choice for developemnt.
3) My suggested approach to refernece an existing code file created using WSP while migrating to WAP, both works as well as fails. It works as you do not need to copy the file, you can directly tell VS where to pick up the code from. It fails because VS copies that file in the WAP project folder 
Depending upon your outlook, that might be good as well as bad. For me, that is bad, coz there are effectively 2 code-bases. If after migrating to WAP, I make some change to code in WAP (say a bug-fix), the WSP file becomes outdated. And if make the fix in WSP, the WAP becomes outdated.
The solution is easy. Just synchronise them, when you update one. But doing it manualy, can get quite troublesome very soon. Need to find a VS way to do it automatically. Haven't tried yet, but believe that I can set a post-build action for both WSP & WAP project, that updates the corresponding files in the other project after a successful build, of one project, effectively synchronising them automatically.
4) There is a .designer.vb file created for each of your module's controls when you create a WAP project. It contains old ASP 1.1 style declarations. And this file is needed with proper control declarations for the WAP project to run.
Now, here's the only major problem while converting a WSP project to WAP. You will need to manually create this file for all your controls, containing all control declarations. This again is not difficult but tiresome. It should NOT be very difficult to create a tool that analyzes an ascx file & creates .designer.vb file for it (The tool would basically need to generate control declarations for each control with an ID tag. The complexity for the control would come from generating Fully Qualified Class names while generating
Dim a as ClassName
This would depend on Imports, Register statement at the top of the ascx file as well as namespaces & assemblies imported in web.config. Still, I believe this tool can & should be developed very quickly.
SO, now I look to comments from other community members. I believe DNN team should seriously consider developing this tool, as this would remove the only practical restriction for converting a WSP project to WAP project, which would provide developers the best of both worlds, development-time productivity (the mantra of .NET) and deployment time flexibility.