Now given that cPython 3.6 has f-string, and that you probably will use string formatting a lot if you script a MS product, I would implement this version specifically. It's the most recent stable version of the standard implementation anyway.
Actually no, I would not implement anything. I would embed the cPython 3.6 interpreter and stdlib, and just provide a binding to it. This limit the problem of bad / inconsistent implementations that crippled MS products in the past.
Then I would say "we guaranty to provide a 3.6 compatible cPython + stdlib for the next x years" so that people can be confident to write Python stuff. Otherwise, a bad implementation would be worst than no implementation at all.
Is it, though? For example, VB puts four different ways of passing arguments right in your face: values by reference, values by value, object references by reference and objects references by value. Python only has the last one and doesn't make you think about it.
And without "Option Explicit" VB does something very unhelpful (also seen in PHP): misspelled variables are created on read and silently converted to the required type, giving you nonsense results. (With "Option Explicit" enabled it gets verbose and tedious instead.)
Yes they should choose Python, and in the process decide if it will be Python with a .Net library (standard and core as seperate libs please!) or IronPython. This in itself is an important first choice.
Then it has to be done in a mechanism that enables the exact same libs and user written python code to work in the same way across all the Office products.
Other languages have been suggested, all good choices with their own merits. Lua is a good chocie for compactness and speed. C# is lingua franca of commercial developers so would suit ISVs but i think too heavy for end user scripting. Nim or even freepascal maybe? Lastly whatabout just using VB.net consistently? VB is a great language for newbs and casual/adhoc programmers .... but it gets ignored because of problems with consistency of implementation by MS.
Last point i would like to make is IMHO the choice needs to be based on: - ability to transpile to javascript so that Excel365 can be scripted from webapps - install-free deployment; should be built into Excel in a way it can be used without any user install for dev or runtime - standard vanilla language, not a variant
Disclaimer: A huge fan and long time user of python here. I also spent largest part of working life in ISV world rather than end user land.