This is in the spirit of the "New Functions I would like to see in future..." post.

I think that one area where Mathematica could improve considerably is supporting and encouraging third-party package development. Mathematica is great for end-users, but it feels like WRI isn't really thinking about making it truly extensible.

A few concrete problems I noticed:

• Recent versions add new symbols to the System` namespace indiscriminately, and prioritize always-present built-in functions over user-loadable standard packages. At 6000 built-in symbols this is just not sustainable and it's hostile to third-party packages: at this rate of adding new symbols each new release is virtually guaranteed to break some package through symbol name conflict.

  Previous versions used to ship with a few new standard packages bundled with Mathematica. Packages felt like a first-class citizen of the Mathematica ecosystem as WRI was using them too. Recent versions never add anything that is clearly a separate package from the user's perspective and needs to be loaded. Instead everything is crammed into the default namespace. Technically, new packages are added in each release, but these are now always auto-loaded and appear as built-in from the user's perspective.

  With the amount of functionality Mathematica has, better namespace management is sorely needed!

  Even MATLAB, long without namespace support, is now adopting namespaces. Mathematica had them from the beginning but doesn't use them anymore, which seems like a step backwards.

  A particularly awful thing about cramming everything into the System` context is that naming conflicts actually break packages, not just cause shadowing. If two packages use the same symbol names, one will simply shadow the other one, but won't break it. If there's a conflict with a System` symbol, the package will need fixes to work again.

• Features that would typically be used by package developers are not well documented or completely undocumented. There are many symbols in the Internal` context that are very useful, such as InheritedBlock, WithLocalSettings, PositiveMachineIntegerQ, etc. There are also many in the semi-documented Developer` context.

• Formerly many features of Mathematica were designed to be extensible and came with some documentation on how to extend them. NDSolve and NIntegrate are good examples. Recent additions tend to be less extensible and more opaque in their working. Is there a way to extend machine learning functions with new algorithms? Or can I add new graph layouts? Can I re-use the built in packing methods for graph layouts in my own layout computation? These don't seem to be possible.

  A good example of how strongly the focus has shifted to the highest level use case while ignoring more sophisticated use cases is the recently added Dendrogram: it goes directly from data to plot, and supports only the most superficial use. The old HierarchicalClustering package has a special data structure for dendrograms which can be manipulated separately from their plot. We had separate functions for computing or plotting a dendrogram, thus we could add our own, separate computation or plotting methods (and I did in the IGraph/M package which does produce dendrograms in this format).

• There are some things that would be really useful or even necessary for package development, but they are missing. For example, how can we clean up temporary files created by packages, on kernel exit? There's no robust solution for this, even though the need must have come up internally (Compile-generated shared libraries do get cleaned up on exit).

• Wolfram Workbench, the only tool for creating proper documentation, is stagnating and the released version (2.0) is not compatible with the latest Mathematica. I am aware that we can request 3.0 beta but it seems to take forever until it gets released. Also, Workbench is only for Premiere Support members, thus difficult to get.

• The licensing that Wolfram offers does not make it easy to create multiplatform packages. One license is for one computer. If a package needs to special case different operating systems (which is always the case for LibraryLink/MathLink stuff) then the only realistic way for most of us to develop a package is to have access to an academic site license, so we can install three copies on OS X/Windows/Linux.

  A company that makes and sells commercial packages can afford multiple licenses. But for a healthy package ecosystem we need lots of free and open source packages, which are not easy with Mathematica at the moment.

To be fair, recent versions have also added very useful developer-oriented tools. LibraryLink seems to be evolving nicely: it got the very necessary "managed library expressions" feature. Associations are not purely developer-oriented, but they are extremely useful in this scenario. 10.4 added support for RawArrays in LibraryLink. I appreciate all these features very much. MUnit, a unit testing package was updated finally added to Mathematica in v10 (and doesn't require the separate Workbench), but unfortunately this update also brought quality and usability problems so in the end I don't use this tool ... the old Workbench version seemed more practically useful.

The point I am trying to make with this post is that I have the impression that overall Mathematica encourages third-party package development less than it used to. This is a bit surprising because there has been a big push to market Mathematica outside its traditional academic niche, to programmers (all the Wolfram Language rebranding, Wolfram Development Platform, etc.). In 2016 a healthy package ecosystem is critical for a software like Mathematica to survive. I am hoping that in the future there will be more emphasis on supporting and encouraging third-party package development.