Delphi 2010 or 2007 for upgrading Delphi 3 project

Project upgrades. The standard advice in the Codegear forums seems to be to manually recreate all project files when upgrading. This is an awful lot of work (7 projects (mostly libs) in our main app, plus half a dozen DLLs, a lot of files.) Is there any way to automate this?

There is: just use the IDE's project importer :)
Seriously, I would just try importing the projects, and then go investigate if it doesn't seem to work.

How's the linker look? We traditionally have a lot of trouble with the linker randomly crashing or running out of resources, though it got a lot better in 2007. This is one reason our main application is split into several libs - the linker cannot (hopefully, "could not, but now can"?) handle it otherwise.

I've had almost no trouble with ILINK anymore since C++Builder 2009. I've occasionally read that others experienced out-of-memory errors, but someone in the newsgroups has discovered a workaround:

https://forums.embarcadero.com/thread.jspa?messageID=140012&tstart=0#140012

Also, as you can read here, the compiler got a new option (-Cx) to control the maximal amount of memory it allocates.

I know there's a new type library editor and format (it stores the IDL, ie text, and generates the TLB dynamically?) How well does this handle upgrading existing COM projects with a TLB?

Should work without a hitch.

I have lots of questions about this, such as "is wstring capable of holding everything a UnicodeString can, and should we just do a search/replace"

Yes, on Windows platforms wchar_t usually is 16 bit large, which means it suffices for holding UTF-16 which UnicodeString is.

or "should we avoid all C++ string types altogether and use UnicodeString"

Depends on how portable your code needs to be. In any case, whenever you just need a string type, use "String", not "UnicodeString".

"can we change all event handlers to use String though the existing .HPPs were compiler-translated to AnsiString"

First, you should NEVER re-use .hpp files generated by older versions of DCC! For event handlers that use the String type in Delphi, you must use UnicodeString. As above, simply use "String", and your code will work for both the ANSI and Unicode versions of C++Builder.

right down to basics such as "should we prefix all strings with L, or is the compiler smart enough with Unicode enabled to use Unicode strings"

The compiler doesn't convert your strings (it would conflict with the language standards), but both AnsiString and UnicodeString do have copy constructor overloads for both char* and wchar_t* string literals. I.e., the following will work:

AnsiString as = L"foo";
UnicodeString us = "bar";

What will not work this way, though, is the whole bunch of printf()/scanf() functions; AnsiString::sprintf() takes const char*, UnicodeString::sprintf() takes const wchar_t*.

If you are using sprintf() a lot, you may find my CbdeFormat library useful; just read my article on the subject.

There are several methods: check Dynamic-Link Library Search Order and Dynamic-Link Library Redirection. The safest one is to put the DLLs you need in the application executable folder, because it's the first one checked. Given today's disk size, it may not be a disk space problem. The DLL may also be not share among processes, but that could not be an issue too.