The current Ashes user interface and game mechanics appear to still be quite traditional-RTS unit-centric, when they could be more army-centric instead.
This post lists army-related issues, and presents solutions to those issues. I invite everyone to provide feedback and ideas for possible improvements! (Can you find a case where it breaks down?)
@Frogboy: Please consider the proposals made, and let the responsible developer have a look at them too-- it took me a while to write this up! At least, do tell where and why things can't be changed accordingly. Thanks!

See also: The first reply in the thread should contain some pictures!

Overview

Army-related Issues:

• (1) Army selection is unit selection
• (2) Armies spread very far; non-visible armies receive orders by accident
• (3) Right-Click on an army is ambiguous (join or get joined)
• (4) Army boundaries and army selection are not visualized
• (5) Army reorganization is extremely cumbersome
• (6) The army reinforcement system is tier-chauvinistic

Solutions:

• (1) User-friendly quick army selection
• (2) Army density invariant
• (3) Explicit "join up with" order
• (2,3) Immediate unit expulsion on invariant violation
• (2,3) Join-invariance rule
• (2,3) "Form Army" semantics
• (4) Army indicator
• (5) Advanced selection and army definition mechanism
• (6) Universal reinforcements mechanism

Army-related Issues

(1) Army selection is unit selection

Selecting armies is done by selecting units that belong to armies. This is not very user friendly: Intuitively, clicking "somewhere" on the blob of units that make up an army should suffice, and the player shouldn't have to "pick a unit" from the blob (pedantic!). That is, there's a lot of empty space around the units (but "in" the army) that currently does not, but should, serve as army "selection target".

(2) Armies spread very far; non-visible armies receive orders by accident

Armies currently can spread very thinly, meaning units belonging to the same army can be spread arbitrarily far across the map. This happens by units getting stuck (which is a bug and will be fixed), but also when armies are joined and reinforced. Now, joining units on screen is not a problem, but reinforcements that drive towards their armies are considered part of the army as soon as they leave the factory. As a result, units are lurking around (bug) or driving across the map (reinforcements) that are part of a much larger army executing orders elsewhere, and there's nothing to (very clearly) indicate that. Because of this mechanism, I have to be afraid of ever selecting single units (or groups) and giving them orders, because that might mess up (order around) large armies far away by accident.

(3) Right-Click on an army is ambiguous (join or get joined)

Ordering the selected units to "join up with" another army is currently ambiguous/non-deterministic. I've been trying to figure out what the algorithm is, but it seems to just randomly/arbitrarily choose a highest-tier unit as the new "core", and let all other units drive towards that one. This is very annoying. The only correct thing to do here (from a user's perspective), is to have the selected units drive towards the right-clicked army and join up with that one, and the target army shall NOT change its order queue or start moving (if the queue was empty). This must also be the case if the target is strictly lower-tiered than the selection! (Don't tell me that the current army implementation can't do this-- then it needs to be fixed!)

(4) Army boundaries and army selection are not visualized

Only the selection of units is visualized (with a bright ring around each selected unit), but how my units are currently grouped ("armied"), and which of those are selected, would be very helpful information to have. That information needs to be conveyed in the world view, not in the UI windows/overlay.

(5) Army reorganization is extremely cumbersome

In battle and elsewhere, the player will want to reorganize armies. This usally means splitting off part of an army (sometimes just one unit, usually T2), then giving the removed units new orders, possibly joining another army and thereby transferring units from one army to another. To split off units, one currently must:

• Press "Disband Army"
• Select the to-be-transferred units with bounding box
• Press "Form Army"
• Give orders to newly formed army
• Try and painfully scratch together the remains of the original army, which is a lot tougher than it sounds, because other armies and separate units might be nearby that shouldn't all become one gigantic army suddenly, and no units of the original army should be forgotten
• Press "Form Army"
• Hope that you didn't mess it up

(6) The army reinforcement system is tier-chauvinistic

Excuse the term, but the army reinforcements system is not very tier-agnostic, currently. I have the suspicion it's due to the high-tier "core unit" problem. This is a clear case of the UI "getting in the way"! The reinforcement system has the potential to be more universally helpful. What it does is this: Delegate a build order to a close-by factory, and have the produced unit join up with this army/unit-- Simple and beautiful. Now why shouldn't this work between any tiers? It is a very common use case! The players inevitably form T1-only armies in the early game, and send them on their adventures. A little later, when those T1 armies have reached "reasonably far" into the map, they must hold position and guard borders. Then, soon, it makes a lot of sense to have them reinforced by T2. Why should the UI not allow this?

Solutions

(1) User-friendly quick army selection

Simple solution: A left click should select the army of the unit that is closest to the location clicked (with a reasonable threshold). This will enable the player to intuitively click "on the army", instead of having to click "on one unit in the army".
Note that in the case of overlapping armies, the algorithm should probably be more sophisticated.

(2) Army density invariant

As an invariant, armies must be strictly forming a dense and convex shape. Or put another way: The amount of units per area in the "convex hull" of all units in the army must never fall below a certain (high) threshold. The effect will be that one army's units always appear to be "more or less together". Battle maneuvers must still be possible, of course.

(3) Explicit "join up with" order

Having units selected and performing a right-click on a unit or army will append a "join up with" order in the selected units' queues, visualized by an arrow-line of distinct color. This order causes the units to drive towards the target army/unit and merge with it (into a larger army), as soon as the density invariant can be satisfied.
Note that the target of such join orders must be completely ignorant to them-- the target army continues to process its queue irrespective of other units about to join up with it.
Note also that the UI should make it clear (by quickly showing the white/purple/whatever arrow-line, e.g.) that a "join up with" order has been given, since a player might otherwise think to have given a "move to" order.
Note moreover that these orders are necessarily always the last order in the queue. When a player issues orders to such units (with Shift), then these new orders will either have to replace the "join up with" order, or be inserted right in front of it, and become the second last order in the queue. I'm not sure which one would be more useful, probably the latter. This would allow a player to quickly assign "side-quests" or "safety detours" to reinforcements, without changing the join-up-with target.

(2,3) Immediate unit expulsion on invariant violation

When, for any reason (bug or otherwise), certain units of an army (would) cause the density invariant to be violated, these units are immediately expelled from the army, receiving a "join up with" order as the only order in their queue with their original army as destination. This will cause them to drive back to the their just-expelled-from army, and merge again with it, if possible.
If units get stuck, this will guarantee that these units can be selected and given other orders in a user-friendly, intuitive manner. It will also guarantee that units moving around by themselves can always be given orders without fear of accidentally affecting armies far away.

(2,3) Join-invariance rule

This one might sound somewhat complicated, please bear with me. I will explain the simplest case-- the full algorithm would need to be more elaborate.
Because of the density invariant, joining units that are far apart will not result in one army instantly, but in many smaller armies that are linked with "join up with" orders. The point here is that issuing orders to such a set of armies that "will be" one army must behave as-if these orders had been given to the full, final army, while still ensuring that the not-merged-yet armies continue to move towards each other and merge, eventually.
Simplest case: Ony of the selected armies has some non-"join up with" orders (the "leading army"), the other selected armies have a "join up with" order with the leading army as destination. Issuing an order now will assign that order to the one of all the selected armies that is furthest from the order destination, and this army will be the new "leading army" and receives the issued order as the only order in its queue. All other armies (that are not leading) will have their queue replaced with a "join up with" order having the new leading army as destination.
I promise, when using it, this will be intuitive-- the units will "do the right thing".
... But the implementor might need to think hard once or twice to catch all cases.

(2,3) "Form Army" semantics

(Note: "Form Army" is not really required, right-click on units would suffice too.)

Because of the density invariant, units that are spread (too) far apart simply cannot be merged immediately. Instead, when "Form Army" is pressed, units are merged only as far as possible until the invariant would be violated. Then, one of the armies is selected as "leading army", and the rest will be as in the "join-invariance rule", above. Optionally, the joined armies could receive a move order to the original center of mass of all originally selected units, since they are being "symmetrically joined together".

(4) Army indicator

Since an army's units now stay reasonably close together thanks to the density invariant, it is (more easily) possible to visualize armies: Where they are, and which units they contain (approximatively). This could be a bounding box (probably not pretty), or a "bar" beneath the units. This bar could then also contain information about the army, like "stance" settings, and how many reinforcements have been ordered but not yet received, and so on.

(5) Advanced selection and army definition mechanism

Proposed actions performable with left mouse button:

• Click: Quick army selection (see above), selects (at most) one army
• Drag: Like now (possibly with fuzzyness), selects all armies that have at least one unit within the bounding box (dragged rectangle)
• Shift-Click/Drag: Like simple Click/Drag, but this adds armies to the current selection
• Ctrl-Click/Drag: Selects individual units, NOT armies. As soon as this has been used (selecting at least one unit, possibly only already selected units), we are in "subselection mode". See below.
• Shift-Ctrl-Click/Drag: Like Ctrl-Click/Drag, but this adds units (not armies) to the current selection, and also causes "subselection mode" to be engaged.

When an order is issued (with right-click, e.g.) while in subselection mode, the following happens:

• All selected units are expelled from their respective armies (if any)
• The selected units are merged into armies as far as possible without violating the density invariant
• The rest happens as in the "join-invariance rule" above.
• The result will be that all selected units will become one army that executes the hereby issued order.

The sequence of actions required to give orders to individual units of an army (possibly for transferring them to other armies) becomes: (Compare to above!)

• Select the to-be-transferred units with bounding box (and hold Ctrl)
• Give orders (can also be "join up with", of course)
• Done.

One major gain with this is that the UI becomes more "army-centric" than "unit-centric", because the player never has an incentive to "Disband" an army. The "Disband Army" button could then actually, and should then be, removed.
It also allows quick "traditional-RTS-style" orders to be issued, ignoring the army-assignment situation for a moment. This can be useful to give "side-quests" to a part of an army, without disturbing the entire army's order queue.
Note: An army that has units removed in this manner should wait a few seconds (ca. 5-10), until it starts rearranging the formation to make up for the new unit constellation, if it was idle before. If the army is currently engaged in combat, it must react immediately, of course.

(6) Universal reinforcements mechanism

To solve the issues concerning tiers and make the army UI more generally useful, the following would need to change:

• A single T1 unit is also an army, w.r.t. the reinforcements interface
• All units can be requested as reinforcements, even T3
• Multiple T3s should be allowed in the same army (the only limit is "total army size")

Multiple T3s is indeed a valid use case, I often end up trying to assign multiple dreadnoughts into one army. Especially 2 or 3 Cronus with few T2 as defense seems to be useful (the ultimate "siege army"), and it wouldn't be larger than a heavy-T1+Hyperion army.