Eugene, what you're seeing is a behavior (I'd call it a bug) of Salesforce itself that I've complained about to them several times. When you deploy, Salesforce decides that those namespace qualifications are unnecessary because you're in the same org, so it removes them. When you retrieve the metadata, you're retrieving Salesforce's version of the metadata instead of the one you tried to save. You can see the same thing happen in the Developer Console. Add those namespace qualifications, save the file, and refresh the window. You'll see that they've been removed. Most of the time this removal is benign, but in Lightning JavaScript and default JSON it can actually introduce some bugs because the namespace is required from "external" clients including the browser.
My comment to Salesforce on the matter is that if a user saves metadata to the server and it's valid, the exact provided metadata should be stored and later returned as part of retrieval. Salesforce should not tinker with carefully hand-crafted source code. Basically there should be 100% symmetry between deployed metadata and retrieved metadata assuming it's valid.
I've worked with some other IC users who want these namespace qualifications retained across deploy/retrieve cycles. The workaround is to use IC's retrieval substitution rules (Illuminated Cloud>Configure Module>Substitution Rules). You can set up regular expression-based patterns for the files which should be processed and search/replace strings. In this case you might say something like:
Filename Pattern = .*\.cmp
Substitution Pattern = \b(\w+__c)
Substitution Text = io0__$1
After Namespaces = true
That will likely require some fine-tuning based on your actual usage, but it should provide an example of how you can undo the "simplifications" that the server is making to your source code.
Feel free to let me know if you have other questions about this, and feel free to let Salesforce know that this is an issue for you.
Regards,
Scott Wells