Not sure where best to reply, will reply here - to the entire thread.
The topic has been briefly discussed before, eg, here.
1. Geometry values do NOT store coordinate system info. They did in Manifold 8, they no longer do in Radian / Future / Viewer. This is intentional. The main issue has always been encoding coordinate system info in a way which would be fast to compare for equality / fast to decode for use / compact / future-proof. Since the time the decision was made we made significant progress on the last two items, but there are still the first two items plus there are caveats, so we don't think storing coordinate system info is a good option.
(Example issue: we could store coordinate system info as a string in the universal format we have now, but a coordinate system definition could be, say, an SRID code specific to the database. If we keep the definition as the code, we cannot decode it, because it refers to the database and the database is not there when we decode. If we expand the code to the actual parameter names and values, we are making it much harder to compare coordinate systems of two geoms for equality - can no longer compare just the codes. Etc.)
2. Since geometry values do not store coordinate system info, it has to be handled outside of geometry functions. Typically, one of the geoms gets projected to the coordinate system of another geom.
Interactive operations do that automatically, the queries they generate include calls to project data as necessary for the operation.
Queries composed manually do NOT do that automatically. Whoever creates a query has to insert calls to project data by himself.
Where we could help:
2.1. Making calls to project data easier. Here, we are open to suggestions. Tell us what specific calls you'd like to see.
2.2. Making calls to project data unnecessary by making operations work on components instead of geoms and taking coordinate system info from these components. We are doing this already for overlays, etc. If there are some other operations between components that you are doing often (clipping?) and you want it to be done as a function that operates on components, tell us. Wrapping an operation into a function that operates on components has its drawbacks because you are losing a degree of flexibility, but we'll still have the original operation available, so that's perhaps fine.
2.3. Making calls to project data unnecessary by making the query engine smart enough to detect when a call to a geometry function combines data from different components and insert a projection call into the middle.
Eg, in the query: SELECT * FROM a INNER JOIN b ON GeomContainsAuto(a.geom, b.geom, ...), the query engine could detect that drawings 'a' and 'b' have different coordinate systems and make GeomContainsAuto do a reprojection. The suffix 'Auto' would distinguish a function that is allowed to reproject data (possibly stronger: a function that is required to recognize coordinate systems for its arguments) from the analogous function that does not care about projections.
This additional logic for the query engine is something we are thinking about doing, but there will perhaps be cases it will not cover.