clarify how ACF save_post is triggered by programmatic methods (eg: post import)

When using wp_insert_post() like does wxr-importer we save posts from an export file.
Such a file may (or may not) contains the field_<uniqid>() meta (eg: if meta does not come from WordPress or fields unique ids changed)
But they do contain the actual meta-key/meta-value registered with ACF:

This is a sample (shortened) WXR file:

<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="WordPress/4.9.1" created="2018-04-24 18:40" -->
<rss version="2.0" xmlns:excerpt="http://wordpress.org/export/1.2/excerpt/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:wp="http://wordpress.org/export/1.2/">
  <channel>
    <description/>
    <pubDate>Tue, 24 Apr 18 18:40:31 +0100</pubDate>
    <language>en-US</language>
    <wp:wxr_version>1.2</wp:wxr_version>
    <item>
      <title>foo</title>
      <pubDate>Wed, 07 Mar 12 20:17:20 +0000</pubDate>
      <dc:creator>me</dc:creator>
      <guid isPermaLink="false">https://localhost/368</guid>
      <description></description>
      <content:encoded><![CDATA[body]]></content:encoded>
      <excerpt:encoded><![CDATA[excerpt]]></excerpt:encoded>
      <wp:post_id>368</wp:post_id>
      <wp:post_date>2012-03-07 20:17:20</wp:post_date>
      <wp:post_date_gmt>2012-03-07 20:17:20</wp:post_date_gmt>
      <wp:comment_status>closed</wp:comment_status>
      <wp:ping_status>closed</wp:ping_status>
      <wp:post_name></wp:post_name>
      <wp:status>publish</wp:status>
      <wp:post_parent></wp:post_parent>
      <wp:menu_order></wp:menu_order>
      <wp:post_type>news</wp:post_type>
      <wp:is_sticky>0</wp:is_sticky>
      <wp:postmeta>
	<wp:meta_key>sources</wp:meta_key>
	<wp:meta_value><![CDATA[1]]></wp:meta_value>
      </wp:postmeta>
      <wp:postmeta>
	<wp:meta_key>sources_0_url</wp:meta_key>
	<wp:meta_value><![CDATA[a:2:{s:5:"title";s:15:"BBC NATURE";s:3:"url";s:36:"http://www.bbc.co.uk/nature/foo";}]]></wp:meta_value>
      </wp:postmeta>
    </item>
  </channel>
</rss>

The file get imported correctly and the backend UI correctly shows the custom fields value's (since these fields must have been registered beforehand).
The issue is that fields won't work in the frontend (get_field() is NULL) because field_ab546aff meta keys are missing although the post was processed using wp_insert_post() on the ACF-enabled WP instance.
(These are repeater fields. The issue does not arise with plain text fields)

• Saving the post manually from the backoffice creates the needed meta.
• Saving the post using wp_insert_post(get_post(368))); will not work (!)

I'd likely attempt to resave each imported post, so that meta get created, but I'd like to know which ACF function to call for each of them. I could not find such a helper so far.

1. why ACF "save" hook(s) reserved to admin backend (and not working otherwise)?
2. which ACF function could serve as a resave-to-recreate-internal-meta-key helper?

NB: this is a long-standing "issue", simply google +acf +wp_insert_post

thank you

Start by tracing the wp_insert_post() and get_post(368) cases against the manual backend save, focusing on the missing field_() metadata for repeater fields. Compare the imported sources and sources_0_url values with get_field() behavior, and consider the issue resolved when the triggering behavior and a supported resave-to-recreate mechanism are clearly identified.