Idea Summary
It is currently possible for an APEXlang application to pass apex validate cleanly and then fail fatally during apex import. Field example: a saved-report displayColumn block with no column: property (a Builder-era data artifact) passes validation because the APEXlang meta-metadata marks column as optional — but the import's generated create_ig_rpt_column_apexlang call then lacks p_column_id and dies with PLS-00306 "wrong number or types of arguments", with a blank File: in the error output. The value proposition of offline validation is "if it validates, it imports"; any validate-clean/import-fatal construct breaks that contract.

Use Case
CI/CD pipelines gate merges and deployments on apex validate (which deliberately and usefully requires no database connection). When a construct passes the gate but kills the deploy, the failure surfaces at the worst possible time — during a deployment window, against a real target, with an error message that names neither the file nor the component. On a large app this means bisecting hundreds of files to find one anonymous block. Validator/importer parity would move that discovery to the developer's desk, minutes after the edit.

Preferred Solution (Optional)
Treat every reproducible validate-clean/import-fatal case as a validator gap: either the property is genuinely required (mark it required in the meta-metadata so validation catches it) or the emitter should handle its absence. Additionally, when an import does fail on a component, the error should always identify the source file and component static ID — a blank File: gives the developer nothing to act on. Stating the parity contract explicitly in the documentation would let teams rely on it.