GGUF Q4_2 / Q4_3 (REMOVED types, type ids 4 and 5 reserved as DEPRECATED)

PROXY ENUM VALUE - DECLARED 2026-10-04 (second proxy class, found in the audit): scheme 'gguf-q5-1' does NOT describe this record. This record is about Q4_2 and Q4_3, two types REMOVED from ggml, and it is filed under the q5_1 enum value because the enum has no slot for a removed type. This is the WORST remaining proxy in the set because it is actively false rather than merely approximate: a query for 'which formats use gguf-q5-1' returns a record whose entire content says q5_1 is unrelated and the named types are gone. Concretely, anyone selecting gguf-q5-1 from a filter would be sent to a record documenting two dead type ids (4 and 5) with .type_size = 0 and .is_quantized = false. REQUESTED ENUM ADDITION: a 'gguf-removed-q4-2-q4-3' value, or a convention that removed types are filed under 'gguf-q8-0' as the neutral legacy bucket. Until then this value must not be read as an endorsement of q5_1. GROUP SIZE LEFT NULL 2026-10-04: Q4_2 and Q4_3 were REMOVED from ggml - the type-trait table entries are stubs with .type_size = 0, .is_quantized = false, .type_name = 'DEPRECATED', and they are absent from the quantizer's QUANT_OPTIONS table. There is no surviving block layout to read a group size from. Any value here would be archaeology, and it would be unverifiable against current code. Weight-only: activations are promoted to q8_K for the dot product and the matmul runs at fp16/bf16, so native_support is deliberately EMPTY and the whole accelerator ecosystem is emulated_support. No accelerator has a GGUF quant path in silicon - this is the single most commonly botched field in this repo. VERIFIED REMOVED, and this is worth recording because older tooling and old forum posts still name them. In ggml/include/ggml.h the enum keeps the slots but comments them out: `// GGML_TYPE_Q4_2 = 4, support has been removed` and `// GGML_TYPE_Q4_3 = 5, support has been removed`. In ggml/src/ggml.c the type-trait table still has entries at those indices but they are stubs: `[4] = { // GGML_TYPE_Q4_2 .type_name = "DEPRECATED", .blck_size = 0, .type_size = 0, .is_quantized = false }` and identically for [5]. They are NOT in the official quantizer's QUANT_OPTIONS table and there is no dequantize function wired to them (unlike every live type, they have no .to_float). So a GGUF claiming q4_2/q4_3 tensors cannot be loaded by current ggml. The old q2_0 / q3_0 / q4_0-series naming from pre-k-quant llama.cpp is likewise reduced to: q1_0 (QK1_0 = 128, 1.125 bpw per the tool), q2_0 (QK2_0 = 64, '2.25 bpw quantization (group 64)'), q4_0, q5_0, q8_0, plus the activated intermediates q8_1 and q8_K. q2_0 and q1_0 are still selectable but are legacy dead ends. SCHEME RECLASSIFIED (parent agent, 2026-10-03): scheme was 'gguf-q4_0' (a proxy recorded while the enum lacked a legal value) and is now 'gguf-q5-1'. NATIVE_SUPPORT CLASSIFIED 2026-10-04: this field is still [] and that is CORRECT, but the empty list used to be ambiguous between three different states and now is not. Reason class on this record: NOT A STORAGE FORMAT, SO THE FIELD IS DEFINITIONALLY EMPTY. This record describes a calibration file, a search orchestrator, removed enum slots or a cross-method summary rather than a wire format, and no accelerator can natively support any of those. Consequence for a reader: nothing further to verify - the question does not apply to this record. The full statement of the three-way distinction, and the worked list of all 72 empty records by class, is in gotcha quant-native-support-empty-means-three-different-things. Rule of thumb for this field everywhere in the repo: if the bits field carries an 'a16', or the scheme is KV-cache-only or a llama.cpp integer storage type, an empty native_support is a DEFINITION and needs no verification; only a W4A4/W8A8/sub-8-bit format with research kernels can have an empty list that is a real finding.