以下嘴砲，加减参考就好。
个人建议是自己先弄出一个基本雏形，
让人可以简单的直接套用或修改。
大前提是让别人可以用现在一半以下的力气达到相同效果，
要学的也尽可能少 (都包好给人直接执行或抄)。
新工具 (测试/版控/相依性) 就看看能不能用命令操作，
能就自己把环境弄好，把命令包好，
让其他人可以直接执行某些你给的 script 就收工。
(ex 输入 project path 就自动做完以下
传到远方你架的环境 -> 更新 lib -> 在你的环境跑测试 -> 没错就 commit)
这部份要做的事简单摘要如下：
1. 架设环境。
2. 练习并摸熟操作方式/命令。
3. 将过去专案需要的功能写成可单键/一个命令执行的 script。
4. 将 3 的 script 做到可在任一机器上执行。
5. 准备好任何误用 (误删/误 commit/拉错 lib/etc) 情形下的解决方案。
然后只要把 script 公开让人取用，
有人想用就用，没人想用可以自己用，
然后假设那真的很有用但除了你没其他人用的话，
你做事应该就会有别人 N 倍的效率，
有助于你爬到能主导的位置或几年后以战功/能力跳槽。
新语法就写个 sample 分 A B 两组，
A 用目前语法，B 用新语法，然后分析利弊得失，
写成文章公开给人存取并提供完整可执行专案。
这部份有几点要注意/实行：
1. 语法整理
前面 ${} 像 jQuery 虽然有点 XD，
但不是全无道理，依字型/大小等确实可能增加辨识的麻烦，
那再考虑是否以 noconflict 把 jQuery 换个变量名与 $ 区分，
能不能简单的 replace 所有档案。
2. 功能确认
原本用的 tag 是不是有哪些特别功能，
例如会存资料到 Request/Session Scope，
或者有亲子/连动等功能或特性，
要换有没有办法全换掉？
或者能不能整理出一套相对单纯而好记好用的 pattern？
例如什么 case 用 EL，什么时候用 tag，
如何组合，有什么原则或要注意的地方等等。
3. 还是功能确认
假设某些 case 你发现 EL 超好用，
那么假设不用 EL 只用目前的东西，
目前的用法有其它改进空间吗？
这部份要花 3 倍的时间去做，
例如原本花 2 小时研究发现 EL 超好用，
那就花 6 小时研究不用 EL 的话最好能做到如何，
要比较两个东西就要把它们都发挥到淋漓尽至，
这是要向别人推销之前的基本礼貌。
这样推成当然好，推不成你也学了不少更有本钱跳槽。
※ 引述《dream1124 (全新开始)》之铭言：
43
: 那是不是以后专案都不可能引入新工具了?
: 结果他竟然很诚恳的说: "对, 确实是不太想导入其他工具!"
: 我了解他是不想唬弄我才会很直接的说,
: 但回去以后越想越气, 怎么连这么小的事情都说不给一点弹性, 方便, 与进步呢?
: 实在是有些不爽, 很想找机会跟前辈上面的人反应这个问题,
: 或是在个人例行报告的会议里面向同部门的人反应我的心声和想法,
: 可是直觉又告诉我这样也许效果不会好, 又会有些可能的副作用,
: 因此上来请问大家一下, 若是你, 会怎么做呢?
: 谢谢大家