Current problems.

• compound requests feel a little bit silly and useless. I dunno if this was the right choice to model addition.
• hard to interact across "levels of abstraction":
  • can't break apart a compound request
  • large difference between what you can do with "5x stone" vs "1x corporea ticket 5x stone"
  • current methods for crossing levels of abstraction feel like hardcoded nonsense (e.g. pulling from an item frame returns the literal item, unless its a corporea ticket, in which case it returns its contents) and are not nearly as intuitive as i'd like

Possible avenues to explore.

• bring corporea tickets back into the world of corporea solidifier and sanvocalia, instead of special cases scattered throughout.
  • Remove the ability to write directly to items in item frames
  • i've implemented the ability to write to a corporea solidifier using the funnel, it produces a ticket
  • nice pairing would be "unticketing" with the sanvocalia. maybe you should be able to write tickets to it using a funnel
    • this would really benefit from a "wildcard interceptor" so you can pull the unticketed request back into the rhodo network, but i remember not wanting to add one for some reason. I can't remember why? Maybe i was thinking of a wildcard funnel, which i really do not like the idea of
• compound request matchers are ordered lists, instead of unordered sets, of other matchers
  • something something, the "furl"/"unfurl" stack tricks from incorporeal 1 might be able to make a comeback
• an opcode that breaks "5x [stone, apple, cake]" into "5x stone" and "5x apple" and "5x cake" in some ordering

oh and i really have to limit the maximum depth of "1x corporea ticket: 1x corporea ticket: 1x corporea ticket: 1x corporea ticket:" before some jackass crashes a server lol. maybe forbid making tickets-of-tickets at all. (compound matchers are already non-nestable)

Things i definitely don't want to add.

• throw more opcodes at the problem without resolving any elegance issues.
• "hashmap order" should never matter, and should be a bug (explicit random shuffling is the best option in the worst case when there really is no best solution)
• Really don't want to add wholly separate datatypes back. i kind of like how there are no type errors in the current system.

oh and i really have to limit the maximum depth of "1x corporea ticket: 1x corporea ticket: 1x corporea ticket: 1x corporea ticket:" before some jackass crashes a server lol. maybe forbid making tickets-of-tickets at all. (compound matchers are already non-nestable)

Unless you make compounds ordered lists (where each element is its own request with its own count), i'd really like to be able to still nest these like at least 20 layers, as a form of ordering a list of requests.

Problem is if you do make compounds ordered lists with their own counts, then you cant use + to add together counts anymore really. or like, if you add 2 of the same thing together does it create a list with those two elements or does it merge and add together the counts (wait a minute, can that be considered equivalent, maybe? it's still a bit limited though, if you consider them equivalent, because if you want to use requests to encode other things than actual requests (music or redstone signals for example), you might wanna have a list with 2 consecutive equal items at some point). Also it would maybe make compound requests a little too OP, since if everything is a request, you'd have to be able to request a whole list of requests, just for consistency, so you could just set up a single request which is a list of all the items you need for a crafting recipe, and shove that right into a single corporea funnel above a crafty crate.

Sorry for big wall of text, hopefully theres some useful feedback in there