it works, if you are interested here's how to do it:
1. create new bcb project, select 64bit and remove the 32bit target
2. statically link (disable run-time packages and run-time rtl) // the rtl does not export all required symbols to allow static linking for 32bit
3. go to infopower source (the package source files are under bin, not under source)
4. load ipstudiowin.dproj and ipstudiowinclient.dproj into a group, go to each of them, clean, in project options, not under linker (they moved it) to Output - C/C++, under C++ Output file generation, select the very last option: Generate all C++Builder files (including package libs) and rebuild the whole group, make sure that both projects have 64bit as the active configuration!). Since these are 170(s), you will find the .a(s) into \xe3 (not under xe4) but in fact they will of course, work! (notice that the static library is not following the windows naming convention anymore, it's a .a instead of a .lib, same about obj(s), they are now .o(s) - gcc style, of course :-)
When you add (the previously installed/registered/etc) info power components to a 64bit bcb form, you will notice that they actually run properly at design time (in the form designer). That is because the form designer is actually 32bit. When you build, you get compiler and of course, the linker would still complain like "where is my iw*.a file". Manually add /xe3 (this should be somehow addressed by the vendor / woll2woll) to the library path and everything will be fine, you get linked just fine and run well.
PS
Same story (well sort of), unrelated confirmation about SDAC (works with 64bit BCB / XE4) if you statically link. With runtime RTL and packages, it chokes with access violation at startup...
Hope this helps both users & vendor