Clarifications. unsub_after was made to fit go client

Signed-off-by: Matthias Hanel <mh@synadia.com>

developing-with-nats/receiving/README.md

@@ -4,7 +4,6 @@ In general, applications can receive messages asynchronously or synchronously. R
 
 Some languages, like Go or Java, provide synchronous and asynchronous APIs, while others may only support one type of subscription.
 
-In all cases, the process of subscribing involves having the client library tell the NATS system that an application is interested in a particular subject.
-
-Under the covers, the client library will assign a unique id to each subscription. This id is used as a closure when the server sends messages to a specific subscription. Each subscription gets a unique id, so if the same connection is used multiple times for the same subject, the server will send multiple copies of the same message. When an application is done with a subscription it unsubscribes which tells the server to stop sending messages.
+In all cases, the process of subscribing involves having the client library tell the NATS system that an application is interested in a particular subject. When an application is done with a subscription it unsubscribes which tells the server to stop sending messages.
 
+If a connection has multiple subscriptions using identical or overlapping subjects (say `foo` and `>`), the same message will be sent to the client multiple times.

developing-with-nats/receiving/unsub_after.md

@@ -4,11 +4,7 @@ NATS provides a special form of unsubscribe that is configured with a message co
 
 The message count you provide is the total message count for a subscriber. So if you unsubscribe with a count of 1, the server will stop sending messages to that subscription after it has received one message. If the subscriber has already received one or more messages, the unsubscribe will be immediate. This action based on history can be confusing if you try to auto unsubscribe on a long running subscription, but is logical for a new one.
 
-> Auto unsubscribe is based on the total messages sent to a subscriber, not just the new ones.
-
-Auto unsubscribe can also result in some tricky edge cases if a server cluster is used. The client will tell the server of the unsubscribe count when the application requests it. But if the client disconnects before the count is reached, it may have to tell another server of the remaining count. This dance between previous server notifications and new notifications on reconnect can result in unplanned behavior.
-
-Finally, most of the client libraries also track the max message count after an auto unsubscribe request. Which means that the client will stop allowing messages to flow even if the server has miscounted due to reconnects or some other failure in the client library.
+Auto unsubscribe is based on the total messages sent to a subscriber, not just the new ones. Most of the client libraries also track the max message count after an auto unsubscribe request. On reconnect, this enables clients to resend the unsubscribe with an updated total. 
 
 The following example shows unsubscribe after a single message:
 

developing-with-nats/receiving/wildcards.md

@@ -1,8 +1,6 @@
 # Wildcard Subscriptions
 
-There is no special code to subscribe with a wildcard subject. Wildcards are a normal part of the subject name.
-
-However, there is a common technique that may come in to play when you use wildcards. This technique is to use the subject provided with the incoming message to determine what to do with the message.
+There is no special code to subscribe with a [wildcard subject](../../nats-concepts/subjects.md#wildcards). Wildcards are a normal part of the subject name. However, it is a common technique to use use the subject provided with the incoming message to determine what to do with the message.
 
 For example, you can subscribe using `*` and then act based on the actual subject.