(My answer didn't fit in the little box, so here's another big box answer.)
I think your notion of "application" is too abstract. An application is a science or engineering field where a model with your desired characteristics might arise. The idea is to find a science/engineering community with a paradigm that values mathematical modeling. Applications include: environmental resource management, airfoil design, drug design, solar cell modeling, etc. A PDE is a type of model. What makes a PDE an application includes choices for model terms, boundary/initial data, variables and scalings, etc. A specific application will determine the available choices. If you try to make "PDEs" an application, then you still need to make all those choices to pose a particular computational model, except you must do so without the aid of science/engineering. Invariably, you end up working with simplistic test problems that the scientists and engineers will call "toys" or (oddly) "Mickey Mouse." This oversimplification-for-the-sake-of-a-demo routinely happens in computational science literature (and it's so annoying). Many PDEs have faux-application names (heat equation, shallow water equations, advection-diffusion equation), which sound like applications, but they're really just mnemonic labels. To understand how $u_t=-ku_{xx}$ might arise in an application, you should find an engineering text on (or colleague interested in) bulk heat transfer. Such a resource should have example problems that set all the terms in the model based on scientific reasoning---instead of being motivated as a benchmark for a different computational modeling tool.
If you're trying to find a range of applications as benchmarks, then you're back to the problem of finding test functions. The problem with a collection of benchmarks is: how does a potential user of your tool know that their problem is like any of your benchmarks? (The optimization test suites have the same problem.) If someone can't see their workbench in your benchmark, then they're unlikely to find value in your tool (e.g. neural net) comparisons. The answer (IMO) is to go look at their workbench.
Re: Question 2. Your categories for application difficulty (continuity, smoothness, integrability) are usually not things that applications engineers think about. Those are things that mathematicians think about. A prominent example: mathematicians have not concluded that the three-dimensional Navier-Stokes equations are well-posed. And yet, engineers routinely approximate solutions to 3D-NS in particular applications. The challenges for a computational fluids engineer usually involve balancing grid resolution, numerical stability, and time-to-solution. Again, there's a large (arguably infinite) gap between mathematical categories and practical computations.
Switching gears entirely. The CFD example suggests a range of abstract benchmark problems that are distinct from mathematical categories. How well does your neural net model balance data resolution, numerical stability, and time-to-solution? There are many functions that could challenge this balance:
- spikey functions
- highly oscillatory functions
- corner singularities
- discontinuous functions
- discontinuous derivative functions
And surely others; just imagine functions where limited resolution will harm your accuracy. Draw pictures. But I stress: if you go that route of trying to list numerically challenging functions, then you're back to the problem of who cares? Specifically, can someone see their own problem within your benchmarks?