Issue 1:
First of all, kudos for what sounds like a great project.

Using exclusively typescript for years, I'm quite excited of being able to use Deno in the future.

Now, I just don't get how it is possible to develop apps at a meaningful scale without a proper module system. I had already shared my concerns once on discord but was not expecting that a 1.0 would be released without any meaningful work in this area.

Because it sounds like Deno approach seems to be influenced by Go on this matter, let me copy and paste an extract from the Go documentation:

Eight years ago, the Go team introduced goinstall (which led to go get) and with it the decentralized, URL-like import paths that Go developers are familiar with today. After we released goinstall, one of the first questions people asked was how to incorporate version information. We admitted we didn’t know. For a long time, we believed that the problem of package versioning would be best solved by an add-on tool, and we encouraged people to create one. The Go community created many tools with different approaches. Each one helped us all better understand the problem, but by mid-2016 it was clear that there were now too many solutions. We needed to adopt a single, official tool.

What's the point of going into the exact same pain points. Why not learning from this experience and avoiding a sure mess to come?

At the very least a proper module system should make it possible to handle versioning and dependency management.

Now is a central repository important or not? Honestly, I'm not really fond of everybody hosts it's publicly available modules in its own git repository because, as a developer, either you are not able to refactor your repository organisation or you will break module installs for everybody relying on your repository. Alternatively, if you do not want to face this dilemma, you will come up with a specific github repository where you publish your modules in order to mimic a "kind-of" group/dev/company central repository.

I tend to believe that a central repository has its use for public modules discoverability and repeatable installation paths but I have no religion on the subject. In the same time, the ability to import modules outside of a central repository (especially when private modules are concerned) is a must have as well.

I'm really interested to read how you guys are seing the development workflow of a reasonably sized app that depend on publicly available modules + internally developed modules with the current Deno module approach.

Issue 2:
I want to get started using Deno but either I misunderstood some core concepts or this really an issue. From what I understand Deno loads all modules on first import and then caches them indefinitely (until you force a reload). My question now is, without some kind of package manager, how can Deno insure quick security updates in modules. Is this even possible without some kind of central authority?

Maybe Deno should think about the option of providing a package information tool (customizable source, but by default deno.land?). Also some kind of option to search for packages would be great. With npm I can just search by keywords and will pretty quickly find what I need.