The picture is not black and white with respect to "new" and "better" technologies. They do not come abruptly. The most efficient approach is to be a little bit lazy and learn technologies when they will become inevitable and reach some critical mass. I am talking about technologies you need to integrate with (to stay competitive) - it's just one side. The rest of the answer talk about the implementation-side technologies, where you have a choice.
Choose technologies on the basis of solving most painful problems first. I am not sure what does it mean canonical versus non-canonical in your question, I think concrete techical solution always solve concrete technical problem.
As a word of warning, I have found it not cost effective to inculcate "newer" approaches to "older" systems. Unless there are some really nasty problems, newer, "next version" technologies make development unnecessary costlier.
Unless absolutely necessary, learning completely new things is better done with toy projects or throw-away prototypes. Working on a new programming project always includes some learning, so a balance should be found (including "fun" into equation - motivational factor for both programming and maintaining).
Getting something right from the start requires experience and thus experiments. For some new domain a prototype, proof-of-concept, etc may be needed first. Product's life cycle needs to be roughly estimated, as well as possible "points of grow". For example, if you are about to hard-code French into the code, and you are vaguely aware that the client is planning to come to US market next year, then include i18n/l10n from the start. Same with Unicode support, timezones, and whatever may be applicable in your case. Yes, it is hard to predict the development of the system, and may be double hard to do it using unknown technology, but if the foundation is right (i.e. architectural decision is not a short-cutting compromise), solution will survive changes in the requirements and future adaptations. Familiarize youself with the problem domain. Solutions tend to naturally evolve (converge) into areas of problem domain (already known). For example, if the customer sells hamburgers, it could be beneficial to make a more general solution, which does not exclude pizzas. In many cases small generalization of the problem (in directions guided by knowing problem domain a bit wider) helps keep solution simpler and does not affect development time negatively at all.
Learn by example: It's very rare situation when you are early adopter of something. And do not include too many new technologies into solution (if possible).
Also, if you do not like refactoring, choose less agile process. Use more time to analize problem and design solution.