Let me get right back to your last point: I have added a little benchmark of the blocking put operation to my example to prove that the put operation is not in pending state and unblocks as soon as :stop is dispatched.
Unfortunately I don't quite get what you mean by a "sole". "Closing from the reader side" is not necessary with the current API.
Now regarding your example:
1) In this point it is not quite clear to me whether you mean to distinguish between "creation site" and putting site. I will assume that you mean both and the same thing and call it production site. My answer would be: Yes. Design your api/program so that you have a close-condition available, even though the producer might be completely generic. One example for such a close-condition is in the example I have linked to: Taking :stop from a seperate channel stops production and closes the channel. The consumer can determine the proper closing time and send :stop, as demonstrated in my example.
2) I know that this is what you want, but you would still need the close condition at the production site to stop putting. Unless you have determined that the channel has been closed, you'd put the next value onto the chan. With the current implementation, such a scenario would heat up the CPU. If you could determine closing on the production site for example by an exception, you would do exactly the same thing as in point 1), but with less information, as I have pointed out in earlier comments.
I believe programmers like "don't do that" much more than "you can't do that". So I think it's fine that you can close! from everywhere. I had some cases myself where very few unnecessary put operations where tolerable as I knew that they would not be possible again after a very short predictable amount of time (In fact when the user clicked cancel: I knew that the interface would be removed from the screen immediately and that a few puts triggered by event listeners wouldn't mind the CPU). So I wouldn't even go so far as to prevent closing. But what I'd really like is that when I develop an API for a library built on top of core.async is this: I don't want to expect channels being closed every time I do a put. I don't want to write an exception-catcher every time. But if what you have proposed would be reality, that would be an unavoidable necessity. Otherwise, I'd never be sure whether values I have put were received, or the channel has been closed. What if I write a function that takes values from one channel and puts them onto another (like core.async/pipe), and suddenly the output-channel was closed? Would I have to close the input channel then as well? Ownership would be totally undefined in such a scenario and lead to all kinds of confusion and most likely lots of boiler-plate code. If I wrote anything that does an unpredictable amount of puts, I'd provide one or multiple facilities to stop the puts.
You may also want to have a look at the C# implementation of the cancellation of tasks: Cancellation tokens are used to determine cancellation on the production site at a specific point in execution order and are passed as an additional parameter: "If library code provides cancellable operations, it should also provide public methods that accept an external cancellation token so that user code can request cancellation." (http://msdn.microsoft.com/en-us/library/vstudio/dd997364.aspx).
Or erlang, where a "finished" message is passed from the production site: http://www.erlang.org/doc/getting_started/conc_prog.html#id67009
Or in go: "A sender can close a channel to indicate that no more values will be sent." and "Note: Only the sender should close a channel, never the receiver." (http://tour.golang.org/#66)
And then there is Haskell, where you can't close channels, but only kill threads...