      - For each load, it places a state marker in the app state at the target destination for the query data
      - All loads that are present are combined together into a single Om query
   - It looks for other mutations
-  - It puts the 'other mutations' on the send queue
-  - It puts the derived query from the `untangled/load` onto the send queue
+  - It puts the 'other mutations' on the send queue (iff they are marked `:remote`)
+  - It puts the derived query/queries from the `untangled/load`s onto the send queue.
 
   A separate \"thread\" (core async go block) watches the send queue, and sends things one-at-a-time (e.g. each entry
   in the queue is processed in a sequence, ensuring you can reason about things sequentially). The one-at-a-time

      not asked for alone). This does indicate that your UI is possibly in a state inconsistent with the server, which
      is the reason for the \"avoid this case\" advice.

  ### Normalization

  Normalization is always *on* in Untangled. You are forced to use the default database format. If you've passed an
  atom as initial state then initial state is assumed to be pre-normalized, but normalization will always be on. Loads
  must use real composed queries from the UI for normalization to work (the om `get-query` function adds info to assit
  with normalization).

  Therefore, you almost *never* want to use a hand-written query that has not been placed on a `defui`. It is perfectly
  acceptable to define queries via `defui` to ensure normalization will work, and this will commonly be the case if your
  UI needs to ask for data in a structure different from what you want to run against the server.

  ### Parameterized Reads

  You may add parameters to your remote reads using an optional argument to data fetch:

  lead to out-of-order execution, and impossible-to-reason-about recovery from errors).
  - You may provide fallbacks that indicate error-handling mutations to run on failures

  ## General Theory of Operation

  Untangled uses the primitives of Om Next, but one of the primary contributions it makes to that model is the
  realization that the following use-cases are by far the most common:

  - Reading data on initial app startup
  - Triggering loads on user-based events (or perhaps timeouts)

  In both cases, the implementation of the remoting in Om Next is very similar:

  - Write something into your application state database the indicates you want to do some remote operation
      - This triggers an internal parsing that you would normally have to interact with in order to decide
        what to ask the server.
      - Note that 'writing something to your app state' is a *mutation*.
  - Morph the UI query into something your server would rather see (you don't want to write server queries for
    every darn UI tree you can think of on the client side)
  - Morph the response *back into UI shape*, and normalize it. Note this is a data transform aided by Om primitives.

  So, the key realization is the *in practice Om reads requires some kind of **mutation** before a read can occur*! The
  additional realization is the after the read run, and you've normalized data into the database, you often *want* to
  morph the database into something special on your UI that the server need not understand.

  So, Untangled provides the 'triggering' mutations, and gives you a way to hook into the result so that you can
  do this post-transform when the remote read is complete.

  ## The `untangled/load` Mutation

  Untangled has a built-in mutation called `untangled/load`. This mutation *can* be used directly from `om/transact!` (and often is).

  The `load` mutation does the following basic things:

  - Places your query onto a built-in queue in your app state of things to load
  - The mutation is marked `remote`, so it will cause the networking side of Om to trigger.
  - The networking plumbing of Untangled looks in the queue when it sees a `load` mutation. It elides the `load` from the remote request itself, and
    instead sends the desired query/queries, then properly merges the results.
  - It may (optionally) place load markers in your app state so you can show in-progress indicators
  - It may (optionally) run post-mutation transforms on the database (if you supply them)

  The mutation can be used from application startup or anywhere you'd run a mutation (`transact!`). This covers almost
  all of the possible remote data integration needs!

  First, let's cover some helper functions that make using this mechanism a bit easier.

  ## Load helpers

  Untangled includes a few helper functions that can assist you in invoking the `untangled/load` mutation.

  1. `load-data` and `load-data-action`
  2. `load-field` and `load-field-action`

  The former of each pair are methods the directly invoke a `transact!` to place load requests into a load queue.

  The latter of each pair are low-level implementation method that can be used to *compose* remote reads with your
  own mutations (e.g. you want to switch to a new area of the UI (local mutation), but also trigger a *remote read* to load the
  content of that UI at the same time).

  ### Load Data vs. Load Field

