These are in no particular order, but are split into "good first issues" (might require some design work but should be doable), and everything else. The wilder ideas are not necessarily feasible, and should be discussed and thought about before we decide if they're worth pursuing. Feel free to suggest more.

Good First Issues

1. Global primitives (e.g. you could write global int x. Currently you have to create a 1-element array to achieve this).
2. A separate location type for switch IDs. Currently these are represented as ints. We'd probably want some way to cast between them.
3. Partial evaluation and variable subsitution pass -- get rid of intermediate variables and static computations where possible.
4. Assignment to individual vector elements (e.g. vec[3] = 7). Likely related to the next point.
5. Allow use of the underscore identifier _ to indicate a variable/argument that won't be used.
6. Add a packet keyword to indicate events which should carry the underlying packet's payload with them. Should be easy to add to the frontend, possibly more work to add to the backend.
7. Restrict events to allow only first-order (no event-type arguments) and second-order (only first-order event-type arguments) events, rather than allowing arbitrary higher-order events as we do now.
8. Allow the return keyword to be used in a handler to terminate computation so the user doesn't have to write big if/else branches.
9. Make the interpreter interactive (let people pause it, insert their own packets in the middle of execution, and maybe inspect the network while it's paused)

Wilder ideas

1. Add a mod operator (or something like it) to implement wrapping around.
2. Allow users to define "size lists", which can be used to construct vectors where the elements have different sizes. Syntax might be something like sizelist foo = [4; 6; 8]; type vec = vector<foo>; vec x = [1<4>; 10<6>; 17<8>];.
3. Better type errors when unification fails
4. Better ordering errors that explain which line(s) and global variable(s) are relevant.
5. Better analysis of when it's okay for entry events to generate non-exit events. Might require user annotations.
6. Built-in security, e.g. events that can't be spoofed.
7. Integration with the control plane. It's there, might as well use it.
8. Integration with P4All. Related to the next point.
9. Automatically finding "good" values for certain abstract parameters, e.g. the size of the array. Could use our simulator, which is much faster than the Tofino's (albeit at a much higher level of abstraction).
10. Functors -- could be used for e.g. chain replication, or adding fault tolerance to certain events.