Why should I choose one over the other?
I see a lot of parachains using orml-tokens, and also x-tokens. Is using orml-tokens required to use all the other orml features like x-tokens?
When should I use orml-currencies? I see for example Mangata using orml_tokens::CurrencyAdapter as the type for native currency, so why have orml-currencies in the first place?
It would be nice to have an in-depth explanation of the difference between the 2, and when a parachain should choose one over the other.
Is using orml-tokens required to use all the other orml features like x-tokens?
No. Every ORML pallets are designed to be modularized. You can use whatever pallet combination you want.
It would be nice to have an in-depth explanation of the difference between the 2, and when a parachain should choose one over the other.
If you check the (not yet existent) feature list of orml-tokens and pallet-assets, it (hopefully) should be obvious that the difference of those pallets.
orml-tokens implements the minimal amount of code to deal with tokens. If you know Solidity, think it as the basic OpenZepplin ERC20 template and that's it. The expectation is that you build additional features on top of it, in a different pallet (one example is orml-currencies, which I will get into it later). This is the general design philosophy for ORML: extensible and reusable pallets.
pallet-assets implements lot more feature including token registration, mint, burn, freeze, etc. If you need those features, great, you can use them. If you don't need those features, well, you need to spend extra work to disable them and the extra code will just make your runtime wasm larger.
So basically, if you need the extra features from pallet-assets, use pallet-assets. If you don't, use orml-tokens. Or for example, if the permission system of the pallet-assets doesn't really fit your requirements, then you can implement a new permission system on another pallet and use orml-tokens to handle tokens.
orml-tokens / pallet-assets handles tokens which is great. But a lot of time people still want to use pallet-balances for native token. It is possible to not do so, but because tooling, life could be easier if native token is implemented with pallet-balances.
But then we also really want to avoid picking pallet based on the token type. Native token is pallet-balances and other token is orml-tokens / pallet-assets? orml-currencies exists to provide an unified way to handle tokens no matter the type. In fact, if you check its implementation, it is just if native token use this else use that. So that the user of orml-currencies does not need to write those if else all over the places.
I have this workshop that could also be useful. It is using a old Substrate version but the idea remains the same https://github.com/xlc/orml-workshop/
I used to ask myself similar questions.
Not long ago I wrote a pallet that was loosely coupled with pallet-assets. Then, we integrated it into GMorDie, which uses an ORML approach instead. This experience allowed me to clarify my mental model a bit.
So this answer is based on my experience with both paths, which is somewhat limited so it is not 100% comprehensive.
Say you want to build some interface where the native asset (via pallet-balances) exposes the same APIs as the other fungible assets in your runtime (via orml-tokens).
You'd give the native asset something like CurrencyId = 0, while the other fungible assets would map to the remaining CurrencyId values. (In practice, you'd actually achieve this with an `enum).
So whenever you're doing stuff like checking some asset's minimum balance or doing a reserve deposit, you can use an unified API (provided by the MultiCurrency trait), instead of relying on some complex matching logic that gets re-routed to different pallets (which would have been the case with pallet-balances + pallet-assets).
GMorDie's runtime source code is actually a good resource to assimilate these concepts.
I know the BasicCurrencyExtended and MultiCurrencyExtended traits also provide some extra functionality (when compared to vanilla FRAME) but my experience with them is somewhat limited, so I'll allow someone else to expand on those.
Same goes for orml-xtokens. I know it's XCM related but I wouldn't be able to provide more detailed insights.
