Read this first: what belongs in Features

[GeneralPawz]

This category is for capability the kernel does not have yet.

Requests start here rather than as issues on purpose. An issue is a commitment
to do work; a discussion is where we decide whether the work should happen. If
every "please add X" became an issue, the tracker would fill with things nobody
agreed to.

The flow

discussion --accepted--> issue --> milestone --> PR --> closed with evidence
     |
     +---declined--> closed, with the reasoning written down

Accepted requests get decision:accepted and become tracked issues. Declined
ones keep their thread and get decision:declined with the reason, so the
next person who wants it can read why it did not happen and argue against the
actual argument rather than guessing.

What does not belong here

Instead you want	Go here
Existing behavior to be faster	Optimization
An API that works but is awkward	Papercut issue
Something that behaves incorrectly	Bug issue

What a good request contains

1. The real use case. What are you building, and what are you blocked on?
   Link the consuming code if it is public.
2. What you tried. Why can this not be solved downstream, or with an
   existing crate?
3. A sketch, not a spec. Enough API or behavior to review. It does not need
   to be final.

Before you request

Check capabilities -- it
separates what is implemented from what is merely represented or planned,
and the status column is deliberately conservative. Also check the
roadmap and the open
milestones; what you want may
already be scheduled.

Explicit non-goals

These will be declined, so save yourself the write-up:

• Making Axiolid an IFC, STEP, or CAD file parser
• Pulling C++/OpenCascade into the dependency graph
• Treating a type, feature flag, or provider seam as evidence an algorithm is
  production-ready