Thanks, Bryan.

The purpose of having two modules in the tutorial was to illustrate how to develop code that, after it's published, will be used as an external resource by other developers. The code in the two modules isn't intended to illustrate multi-module development -- one module is "in development" while the other is a mock client. So it's an opportunity to show workflow with for calling code in another module in order to test it before it's published (via replace).

I think that adding a topic about cross-package calls inside a module would be fine. But...

...having said that, I'll say that I think this tutorial was poorly conceived (by me). I think that a tutorial with its title should focus on module mechanics, including the interaction items you mention, but also versioning and some of the other common module development workflow items.

Instead, the tutorial starts off about modules, then skips through a lite Go language tour of error handling, slices, loops, unit testing, and ends with a few build/install commands.

I wonder if we should redesign this tutorial, possibly with the result of having two tutorials instead?

What do you think?

I think a redesign, perhaps with two or even three tutorials, sounds good. Perhaps one tutorial on writing a (multi-package) program within a module, and another on publishing (and testing) a library for others to use?

Yep. Those ideas work for me. I'll see what I can come up with and suggest something.