Sorry, this will be definitely a won't fix for QMapShack. It's out of it's scope. The experience with QLGT has shown that putting everything in one application is a bad idea as it will increase dependencies. That is why map creation and export won't make it into QMS.
I might start with a stand alone application for referencing maps. However my need is very low as all of my maps are perfectly referenced by now. And using QLGT to reference new maps is a much easier way than to start a new application. So chances are low.
Hmm, but vrtbuilder integrated, why? It also "putted everything" :-) Another question, if Map Referenced tool will be ported from the QLGT as a tool like VRT builder, will pull request/patch be accepted?
IMHO good application to work with rester maps must have reference tool too. In this way it can be used as drop-in replacement for OziExplorer (and Glabal Mapper in most cases).
VRT is not really a map format. It's a wrapper around several files. The same as the *qmap container in QLGT. As in QMS you have to give paths rather than map files, each map has to be defined by a single file. And building a vrt file is a very simple way to combine several files without starting to merge all these files into one physical file.
Referencing is a totally different task. It's very complex. Starting with a GUI to preset all reference points and to adjust them to a grid. Next you have to start a cascade of GDAL tools to do the referencing. And it's really tricky to do it right for all kind of sources. I used QLGT to reference files, resulting in large 32 bit RGB files. To convert them into a single file with a common color table with transparent channel I had to do quite some step manually. So it's not only porting code, it's analyzing and improving the complete process. Not a task for an afternoon with bad weather. This is spending several weeks of work.
Also referencing has a complete different demand on the render engine than displaying maps and data. Thus putting it into the tools section won't really benefit much from the existing QMS framework. It will be more or less a widget with a lot of other widgets and objects that could be easily integrated as main widget into a standalone app.
As for a pull request: If the request is not breaking anything, if the code is readable and well written and thus maintainable, if there is a chance that the task will be finished up to a certain perfection, in that case I will not reject a request. But be warned: If you start it, you will spend a lot of time. That is not a bad thing in the first place as you learn a lot. But it will be more time than simply using existing software like QLGT. The experience from the past is that people donating very complex chunks of code lost interest after reaching their personals goals, leaving the project with a huge heap of code that needed bug fixing and improvement. So you really have to be committed to the task.