First of all, this is remarkably good and clean code! Nevertheless, I do have some things to nitpick on:

Code Formatting

Let's talk about line length. As of right now, you have a (physical) line in your program weighing in at a whopping 160 characters.

First off all, this is easily enough to make the code blocks here on code review have a horizontal scrollbar, which is impractical and not very beautiful.

Second of all, 160 chars is too much for many of us to handle in a typical development environment. Maybe you have a nice, big monitor or two which allow having open four files simultaneously at a line width of 200 or more. However, I certainly don't, and making me work with your program on my 14" diagonal laptop with about 200 characters line width for the whole screen is not very accommodating of you.

Now, the correct maximal line width has been a matter of ongoing debate. I'm an advocate of the good old 80 characters standard, but I'd argue that anything around 100 characters is fine. However, in my opinion, 160 is not; and you are likely to upset some people by sticking to it.

Another issue I see is horizontal spacing. For example, let's take a look at two lines from your code:

pos         += formater.back().size();

Dynamic     newDynamic  = formater.back().isDynamicSize();

Both of these are to be found in the body of the Format constructor. Obviously, you are trying to align you definitions/operators. Even more obviously, you are failing at it. Although both of these lines align with something, what they align with is not all easy to recognize. I don't know whether this is the fault of a tab-width mismatch between the code block and your original code. All I can say is that that indentation looks out-of-place, and left me confused the first time I glossed over your code.

In general, aligning initializers etc. is completely acceptable, but you should refrain from doing it if the alignment reference is not at most one line away. Otherwise, it will just look strange, and overall a programmer's as good as you unworthy.

About char const*

Ah, C-strings. Don't use them unless you definitely have to. Why? Because...

1. They are inherently unsafe. You have no guarantee that the pointer you receive is a pointer to a valid, zero-terminated string and not to anything else, like an array of binary data, or nowhere at all.
2. C-Strings are dumb. They don't contain length data, nor anything else besides the address of their contents. Usually, you are wasting performance here by having to call strlen on a string whose length is theoretically known at compile time.

What are the alternatives? Since you seem to be using C++17, this is an ideal use case for std::string_view. If this is not the case, then the guidelines support library offer as variety of string spans. If both of these options are blocked for you, you could template your way out on the type of the parameter. As a last option, you could also just simply take a std::string const& or std::string&&.

About getNextPrefix

Overall, this method seems a bit unclear to me. Starting right from the definition, why do you have an anonymous first parameter? What is the point of it? This seems highly dubious to me. There are only few reasons to have such a parameter anywhere in the first place, and none of them seem to apply here. Does this method follow an interface requirement that you did not tell us? Seems unlikely since it is private.

Following, what kind of Frankenstein string is mes? When I was reading through the Format constructor, I was really confused at first because those last strings in the calls to this method didn't seem to make a lot of sense. In fact, these strings only make sense in the context of getNextPrefix.

It seems to me like you were hit by a sudden case of design pattern madness: Valuing the DRY principle above everything else, you reduced those two message strings to the bare minimum, divided every common divisor out. If this were normal code, that would be most likely fine, but we are talking about strings here.

Even if this method is private and no user ever would have to deal with this quirky interface, think about what you are actually doing when you are defining any method. You are abstracting away a certain functionality behind a name, and this name now has to convey its meaning where it replaces the code it contains. In your code, however, nothing conveys the fact (which is not at all obvious) that only part of a sentence should be passed to mes.

In general, splitting up what logically belongs to a single part of a string (such as a sentence, a phrase, a name, etc. depending on context) is almost never a good idea. You are certainly decreasing readability, at the gain of a few characters of saved code.

Another thing I am not a big fan of is using numerical indices instead of iterators. Doing so gains you very little, but decreases the semantic integrity of your code. After all, std::size_t is not a very useful name. All it says is "this here is an unsigned number", while std::string::iterator expresses "this here is a position in a std::string".

Iterators do have some drawbacks, such as the possibility of invalidation if the underlying container is moved, but those do not apply here, since everything you do that could be written using iterators is a single logical action.

This would also get rid of the (arguably) ugly std::string::npos, and the ugly find method of std::string (to be replaced by std::find).

One last point: std::function is quite heavy implementation wise. While it is, in general, not a design problem at all to use it (and I would go further and say that it is even a good practice), it can have pretty heavy stack and performance drawbacks. If you don't mind those, you can go on using it. If you do, you should make the type of test a template parameter, or go with the C way of passing a simple function pointer (which is arguably much worse style-wise, but better for code size).

Ignoring Values

std::ostream* ignore[] = {&printValue<I>(s)...};

is pretty ugly. In my opinion,

static_cast<void>(printValue<I>(s)...);

looks much nicer.

Includes

You are missing an include for std::size_t. Preferably, that would be #include <cstddef>, although there are at least five other headers guaranteed to define it. Similarly, you are missing #include <utility> for std::move, std::pair and the whole std::integer_sequence package, and #include <functional> for std::function. Finally, you are also missing #include <algorithm> for std::remove_if, #include <iterator> for std::begin and std::end, and #include <tuple> for everything std::tuple-related. Please be more careful around your includes!

Another thing that bothers me a little is that your include are not sorted alphabetically. While this is not a problem per se for such a small project as yours, it can grow to be a quite a nuisance in larger projects with dozens or more of includes. Ordering your includes from a to z makes getting an overview over them much easier and helps verify whether all includes are actually there.

Typos and Spelling Inconsistencies

Finally, the most pedantic and least useful code review point of all!

Format contains a member variable spelled formater. However, in the constructor, you have the comment

// Convert the next part of the string into a Formatter object.

Since "formatter" with two 't's is the correct spelling of the word, you might want to change you variable name.

Another comment of yours reads

// Take into account the Dynamic Width/Precesion prevent the format from being read.

I assume you meant "Precision" here.

In general, I would like to appeal to you to make more use of commas and punctuation in general throughout your comments. For example:

// For each argument we pass
// Pass a prefix string (might be empty) the formatter then the argument.

would be more correct (from a language point of view) if written as

// For each argument we pass:
// Pass a prefix string (might be empty), the formatter, then the argument.

I personally find it very important to not be sloppy with code (as I presume you do, since if you didn't, you would not be coming here for code review), which includes comments. The reason is that introducing sloppiness at one point tends to carry over to other parts of the work, at least for me. More importantly, however, comments are a way of communicating with other programmers; as such they should be clear and easy to understand, which is somewhat hindered by bad orthography and grammar.

This answer turned out to be kind of a massive wall of words. Most points I mentioned are opinion-based to a certain degree, so please take most of these as a 'Please consider...' instead of a 'Do!'. However, there is a single point which does have this imperative nature, the first point mentioned under Includes. If there is only a single thing you consider from this answer as a whole, please make it that point, since it severely endangers the validity of your program.