Just thinking out loud, I'd guess it ultimately depends on what you want for accuracy, and where you want to make accuracy tradeoffs, especially in the case of new data that you want to fit into existing data. If you just want to take something from CAD or a metes and bounds description and, without regard to the precise details of other content, place it semimanually someplace on Earth (which is what the process of scaling and then move/rotating it boils down to), that's straightforward. A scale tool only needs to provide three points, which could easily be two lines that each have a dimension, or, if X and Y scale are assumed to be the same, just two points with the distance between them. Move and rotate is likewise straightforward. I could see such things added to Manifold as part of the georegistration toolkit. But there is more to consider if what is being semimanually georegistered is required to correctly align with existing data. Suppose you have a parcel map that's in some sense "official," in that it's the baseline for some tax office or central cadastral registration of real estate. It shows a bunch of parcels, with open space off to one side. OK, now you want to add a real estate development that fills in that open space as subdivided into new parcels. You get that drawing of parcels from some CAD or other format where the dimensions of the parcel boundaries are claimed to be exact, but the format isn't in any coordinate system has has anything to do with the planet Earth. It's just a CAD drawing in abstract Euclidean, XY, space. You want to import that CAD drawing and georegister it so that the kinked boundaries of parcels align perfectly with the corresponding kinked boundary at the edge of the baseline collection of parcels. One side effect of the Earth being a 3D shape and the CAD drawing being flat is that when you reproject (which is what georegistration really is) that CAD drawing into any Earth based coordinate system you're almost certainly going to face a choice: either a) The vertices that define the shape of the parcels being added will exactly align with the vertices that define the edge of the existing parcels, in which case the new parcels you add will snuggle right up to the existing ones with no unseemly overlaps or gaps, or b) The lengths of the segments (the dimensions) marked for the line segments that define the parcels will remain exactly as specified, in which case the vertices won't match and you will end up with overlaps or gaps. It seems to me the above are the likely best cases. If the CAD drawing is not internally consistent it could be that a regular reprojection (i.e., between known coordinate systems) would be insufficient and that the data would have to be warped in some irregular way, as done with spline transformations, for example, for the vertices to fit. If your standard of accuracy isn't very high, then you might get away with it, with vertices aligning and, not looking at too many decimal places, the dimensions remaining the same as originally claimed. But even simple effects like the ellipsoidal flattening of the Earth are about a 1/300th effect, over 3 millimeters in a meter, or 1/3rd of a foot in a 100 foot property. Getting 1/3rd foot off in a hundred feet is grossly inaccurate for a modern survey. With a quality CAD drawing done well you might not see anything so gross, but I wouldn't be surprised the transformation process caused some discrepancies out there in the sixth or greater decimal position. There is a somewhat related issue in traverses, where it is routine to get a traverse that does not "close" if you take the linear dimensions and angles literally. Follow the traverse directions exactly, and you don't end up exactly at the spot from which you started. ESRI has a tool for that (Manifold will sooner or later), that adjusts all the traversal dimensions and angles evenly across the entire figure to achieve a close, but doing that is changing the numbers. You could do something analogous in this case, if it was necessary for an addition to a official standard to have to conform to that standard, at least along the edges where the addition touches the official standard. Without knowing the specifics of demand, I'd guess (just a guess) that a simplified Affine, basically an "order 0.5" (that's humor, not a mathematical statement...) would be higher priority in cases where you want to align to existing data. After all, when you have visible vertices along the edges that are supposed to come together it's easy to click a few and get a fast and easy alignment. If the dimensions end up being slightly different from the original in the sixth decimal place, that's probably as good as you're going to get in any event given the nonspatial starting data.
