Say you have a Base class and a derived class. Unless I'm mistaken, the following code is valid

Base base=new Derived;

Yes - and it's not just valid it's also good practice:

http://www.fatagnus.com/program-to-an-interface-not-an-implementation/

And you can type var (C#) or auto (C++) or whatever if you want the compliler to recognize the type automatically.

(But it disguises the type e.g. if the return value of a function is not clear.)

And in C++14 you can write this as long as the range supports a push_back method of value type

auto add_value_to_range(auto range, auto value) { range.push_back(value); return true; }

In templates only, or regular functions? That seems like it'd have to be a compile-time template.
The return value makes sense (and is already supported in C++11, but is being refined in C++14), but as parameters, if the function is overloaded, that seems like it'd introduce ambiguity. Are auto parameters the last to be resolved only if the other overloads don't match?

C++ examples of why the syntax needs to support having them on both sides:

//As dawgdog mentioned
MyBase *base = new MyDerived();

MyType type; //Left-hand side needed, because no right hand is specified.

//Right-hand needed, because no left hand is specified.
myFunction(MyType());

//Unnecessarily redundant, but validly. Type on both sides.
MyType type = MyType();

//Left-hand needed, but since it's already present you can just use auto (as others already mentioned).
auto type = MyType();

I'm assuming you're referring to C# here since all the examples you've mentioned look C#ish and not C++ish, and you mention Unity, which has no C++ implementation. though you may be referring to Java as well.

In C# all variables full under two categories. The narrow category of Value types, which are all the built-in primitives (int, float, char, etc), and the much broader category of Reference types which is any class or template type.

If you're most familiar with C++ it's easiest to think of Value types as variables on the stack and Reference types as variables on the Heap. And as any variable on the Heap in C++ must be Instantiated with new, so must any Reference variable in C# be instantiated. Unlike C++, Reference types can only be instantiated on the heap. There's no way to automatically create a local instance of a Reference type.

In templates only, or regular functions? That seems like it'd have to be a compile-time template.
The return value makes sense (and is already supported in C++11, but is being refined in C++14), but as parameters, if the function is overloaded, that seems like it'd introduce ambiguity. Are auto parameters the last to be resolved only if the other overloads don't match?

It's regular functions and even lambda captures, thats the whole reason for it. This explains better: http://herbsutter.com/2013/06/13/gotw-93-solution-auto-variables-part-2/

Example code from article in base form:

function<void(vector<int>)> get_size =
     [](const vector<int>& x) { return x.size(); };

Rewritten to use auto:

auto get_size = [](const auto& x) { return x.size(); };

this will work for any object passed to the lambda that has a size() function defined for it. It pretty much allows you to write duck typed code in C++

I can't see where the linked article talks about auto parameters in normal overloaded functions, am I missing something?
Return values, yes. C++11 has that in some limited cases already.
Template arguments, yes, that makes sense. Lambda arguments make sense (lambda auto parameters could be compiled as templated arguments), but normal C-style C++ functions can't change their arguments... Are auto-parameterized functions secretly template functions in disguise, generating additional compile-time overloads?

Well, what brought it up was reading up on using lists in Unity, and their example was

List<T> myList = new List<T>();

To me, it should be a no brainer, "Hey, I said myList was "List<T>" so it should probably be a "new List<T>"

If you are coming from a C or C++ background, know that C# is a different language.

If it helps you transition, you can think that in languages like Java and C# all variables are secretly pointers. They don't look like pointers, but myList is really a pointer to List<T>. If you type SomeObject obj; the equivalent C++ would be SomeObject *obj;, a pointer rather than an instance.

Again if it helps to make the transition, think of it as a conspiracy. The writers of these new languages don't want you to know about pointers. They want you to forget pointers even existed. So variables are really pointers to objects rather than objects; instead of the -> operator on these secret pointers they use the . operator to try to confuse you. That's also why the languages use dot for scope resolution rather than ::, to make you forget about your true roots, trying to tempt you with an easier way rather than the true path of hard work and struggles.

Once you are indoctrinated to the secret cult of modern programming languages you might discover that it frees your mind to work on other more important issues. But for now, they are just trying to cover up the truth. Pointers are hidden to just use a dot. Scope is hidden to just use a dot. Who knows what critical truths of programming they will hide next behind the dot.

Be careful about drinking from the punch bowl, because until you do you can rest assured that there are serious performance penalties for hiding pointers, that hiding pointers this way will upset every performance metric, and that every time a pointer is hidden this way a puppy gets drowned. This is why it is important to stick with C and C++ that have their roots in 1950's model, rather than those hippie/punk/goth kids using languages with a 1990's model. If you are forced to use their languages, always remember that you really are dealing with pointers when they want you to think you have objects.

Until your mind makes the transition, know that in these sneaky modern languages everything is secretly a pointer, to appease the secret pointer objects must be made with <i>new</i>, and they want to deny the existence of <i>delete</i>. They are a cult of satan using a powerful drug, be careful when working with the code lest it addict you. :)

Frob, this was the single most funny thing I read here in weeks :D ROFL

That was kind of funny, but it's actually more informative than funny. I do wish people that learn Java as a first language would know that much, so they have a mental picture of what's likely to happen under the hood, and therefore make reasonable estimates of the performance some way of implementing something will have.

In particular, I seem to encounter a lot of people trying to write an alpha-beta searcher (chess, checkers, connect-4...) in Java, and they don't understand why their programs are two orders of magnitude slower than commercial programs. The answer is typically that they are doing a whole bunch of dynamic memory allocations per node visited, which is unacceptably slow. And yes, for some types of programs (the vast majority of the programs I care about) performance still matters, certainly in the two-orders-of-magnitude scale.

I was going to ask what mechanisms in Java and C# I should recommend to people with this problem, but I think that would be too much of a thread hijack. I'll ask whenever I find someone with that problem again.