Dear OP.
you’ve been given sound advice by the Esteemed Forumers. This is just my take on answering your questions; it might be easier to follow, or not 
When you want to do firewalling, there are certain things you have to be aware of. In no particular order.
In the networking stack, the packets follow a path described by the packet flow diagram. There are many versions of it, my favorite is this one
https://stuffphilwrites.com/2014/09/iptables-processing-flowchart/
The only difficulty you may have with this, is that it’s labeled based on iptables (so general linux) terminology, but it’s actually accurate and useful. Mikrotik exposes this system through it’s configuration almost exactly, so it’s only a matter of translating some names. (You should just disregard the boxes labeled “security” - these are not available and were thought up for a quite specific purpose. These not existing doesn’t in any way imply any security risk.)
The firewall is consulted at many different points during a packet’s journey. These involve the execution o a specific chain. So to answer one part of your series of questions: the order in which the rules from different chains are placed or interspersed have no bearing on their execution. It is customary to keep the rules for a given chain together, but that’s just for us humans.
In a given chain, the rules are evaluated in strict order. This means that within a given chain, the order of the rules matters, and is actually very important. The rules always have a “match” part, that is: for what packets should this rule be triggered. And the rules have an “action” part, that is, when a match occurs, what should be done. The fate of the packet is decided by the first rule that contains a “final” action; that action is then taken and no further rules (in that chain) are executed, nor even consulted. What exact actions are “final” is documented in the Mikrotik help pages, but it’s kind of obvious based on what they do: “accept”, “deny” - the ones most routinely used in filter rules are final. Some actions (such as “add source address to address list”, do what they say, but basically only as a side effect - the packet’s fate yet undecided, processing continues.
One of the major features of the firewall is connection tracking. IP is - by its design - a connectionless protocol. However we find it extremely useful to associate packets with a connection they “seem” to be part of. “Seem” if written, because this connection and its state only exist in the “mind” of the router, and are based on observation of the headers of packets passing through it, and therefore might not match what the actual endpoints of the connection think of the connection.
Connection tracking (very roughly) enabled two major things, which we like very much:
- Allowing connections based on where (on which side, network, etc.) they were initiated from. A typical example is that we want to allow internal (LAN) devices to be able to initiate connections to the outside world (WAN), however we want to deny initiating connections in the opposite direction. The key word I keep using here is “initiated”, because of course WAN->LAN traffic should be allow if (and only if) it is a response to something initiated from the LAN side - this is where connection tracking comes in: we have to remember that there was an outgoing packet, and be able to associate the reply with that connection.
- Allowing the usual NAT. WAN-side outgoing messages have to have their source address altered to (the usually single) routable IP address provided by the ISP. Response traffic will then be addressed to the external address, and so has to be translated to the address of the device who sent the outgoing packet - thus again we have tot make note of these connections to be able to do this correctly.
Mikrotik allows you to turn of connection tracking altogether. This is done only is special cases. The firewall also allows you to specifically instruct it not to apply connection tracking to certain packets - this is done in the “prerouting” chain, with the not so creatively names “notrack” action. Again, this is special configuration. I am only writing these things down because you ask; I’ve known people who have configured firewalls for decades (and did so in an appropriate and secure way,) who didn’t have to deal with any of this. I suggest that you leave these for later.
A packet that has gone though connection tracking has a “connection state” assigned. It is assigned exactly one of these: new, established, related, untracked. In order:
- new: we tried looking up this packet, but see no connection we can associate it with; if this packet is accepted, a new conntrack entry will be created
- established: we have a conntrack entry for this packet (so basically it isn’t the first packet of the connection)
- related: this is special one; sometimes there are packets that can be associated with a connection, but don’t match the signature; a typical example is that one of the routers forwarding your packet sends an ICMP error or advisory, such as: Destination unreachable, No route to host, Fragmentation required, Lifetime exceeded, etc. Generally these are treated the same as established.
- invalid: we have a conntrack entry, but something is off with the flow of packets (this is the assigned state e.g. when one side has sent a message closing a TCP connection, and there is further sent from either side.) - these packets are usually dropped
- untracked: the firewall was explicitly instructed not to engage the conntrack machinery either for lookup or possibly to introduce a new entry
Regarding Mikrotik’s default firewall ruleset. These are well written and provide the recommended basic level of protection that’s considered adequate. (Most consumer type routers apply a very similar set of rules, just most don’t expose the configuration.)
However, I think that Mikrotik’s rules are written a bit too cleverly. I must state again that the rules are absolutely correct as written, the following is just a bit of philosophical nit-pickink:
- Some of the rules do “too much” in one go. For example the fasttrack rule has an exception for ipsec. This is fine and correct, because you want to exempt ipsec traffic from fasttrack, however this can be more clearly written in two rules. The same goes for others.
- The firewall system allows you to “program it” in many different ways to achieve the exact same behavior. I think that the rules generally reflect the thinking of the one creating them. I generally like organized thought. This is why I usually filter based not on what to block, but describe/list specifically what I want to allow, and drop all else. I think this is the correct way of thinking about things.
As to your last remark, filtering basically involves three chains:
- input - traffic addressing the router itself
- forward - traffic forwarded by the router (generally between two networks)
- output - traffic that is generated by the router itself
So what you are referring to in your last post (if I understand correctly) is traffic initiated by the router itself, let’s say for example a DNS request. The outgoing packet traverses the output chain. (The output chain is usually left empty, and by default it is therefore accepted.) Together with accepting the packet, a conntrack entry is created. The reply packets traverse the input chain and because they have an associated valid onntrack entry, their connection state is established.
