Its own language.
Its own direction.

Familiarity is a starting point, not the identity.

VOID uses C#-inspired syntax because that style is productive for game code. It is independently designed, owns its own parser/semantics/runtime, and compiles to native code through C.

Focused does not mean artificially small.

The language already supports a substantial managed feature set, nullability, modern initialization, generic collections, runtime metadata, native interop, and unsafe escape hatches without inheriting a general web/application platform.

Familiar object semantics should compose normally.

Constructor chaining, inherited interface contracts, struct interface values, virtual properties, field-like/custom events, expression-bodied members, constrained generics, delegates, and target-typed conditionals are implemented as one coherent object model rather than isolated syntax features. Integration milestones deliberately prove that these features survive normal GC and multi-file use together.

Value semantics should survive real composition.

Nested and readonly structs, jagged and rectangular arrays, null-conditional indexing, explicit/inferred rectangular initialization, closure frames, iterator state, do/while, managed references, compound targets, and unsafe members are designed to interact through one compiler/runtime model. Integration work deliberately forces GC and mixes these features so value layouts and control flow are proven under real composition rather than isolated syntax.

Cleanup is part of control flow.

Exceptions, finally, rethrow, iterator suspension, IDisposable, foreach disposal, using, and structured exits share one cleanup/unwinding model. VOID does not treat resource lifetime or exceptional execution as permission to skip GC-root restoration, pending cleanup, or native boundary rules.

Abstractions should reuse existing dispatch.

Extension methods reuse overload resolution, constrained static calls reuse monomorphized generics, and default interface methods reuse the interface system. New syntax should not create a second call model when the compiler already has one that can express the behavior.

Flow-sensitive syntax should reuse normal semantics.

Declaration, logical, property, and recursive patterns reuse normal type relationships, getter semantics, definite assignment, short-circuiting, conversions, and GC-safe temporaries. Pattern switch statements and switch expressions build on the same matcher instead of creating separate pattern engines.

Generic lowering must preserve why code was legal.

Constrained operators are authorized by generic interface contracts before specialization. Iterator and closure transformations preserve that generic origin and constraint provenance when locals become generated fields, rather than letting transformed concrete types silently lose the semantic contract that permitted the operation.

One semantic model should serve every tool.

Builds, voidc check, live diagnostics, hover, signature help, completion, navigation, references, symbols, and voidc lsp all reuse compiler-owned parsing, project resolution, source state, and semantic information. VOID does not need a second language implementation hidden inside an editor plugin.

Close real restrictions, not roadmap vanity metrics.

Completion phases are driven by explicit compiler restrictions and integration failures: static interface contracts, constructor flow, iterator locals, receiver expressions, generic calls, callback ABI edges, and project output were closed because ordinary game-oriented code could hit them. The roadmap stays phase-based even as the internal milestone count grows.

Use standard native mechanisms where they fit.

Native C output, system compilers/linkers, C ABI interop, reusable static-library archives, stable exported C symbols, and standard debug line information keep the low-level path understandable and portable instead of inventing custom machinery without a reason.

Engine and Language remain separate.

VOID Engine and VOID Language are designed to complement each other while remaining distinct projects. The Engine keeps its current C#/.NET foundation, and the Language remains independently useful.