Can you elaborate on what you mean?

If I have to serve a mapped image with different dimensions e.g. for different resolutions/devices, as it happens in responsive design, or otherwise if the image has to react to window resizing, the areas in the associated map do not follow the resizing. But areas don't follow, so they no longer correspond to image areas. Notice that adapting areas in client-side maps is much easier than programming the server-side map to interpret the position of the click when the image has been resized. But currently it must be done through a script.
Here's my idea, for what it's worth. The map should have dimensional attributes. They could be "width" and "height", or a unique "dimensions" attribute if you think that width and height may cause confusion (the map itself is not palpable). Here's the relevant point: when the the img element whom the map is associated to is resized by CSS, the user agent interprets it and the resizing algorythm is applied to areas too.
An example:

<img id="planetgraphic" src="http://www.w3schools.com/tags/planets.gif" width="146" height="126" alt="Planets" usemap="#planetmap">

<map name="planetmap" width="146" height="126">
  <area shape="rect" coords="0,0,82,126" alt="Sun" href="sun.htm">
  <area shape="circle" coords="90,58,3" alt="Mercury" href="mercur.htm">
  <area shape="circle" coords="124,58,8" alt="Venus" href="venus.htm">
</map>

Now, the document above is associated with the following rules:
#planetgraphic {width:292px;height:auto;}
The user agent will resize linear dimensions for the image, doubling them (the calculation is already native for {height} in the case above).
Now for the map areas, they will be applied changing the coordinates as follows:

area shape="rect" coords="0,0,164,252" alt="Sun" href="sun.htm"
area shape="circle" coords="180,116,6" alt="Mercury" href="mercur.htm"
area shape="circle" coords="248,116,16" alt="Venus" href="venus.htm"

As you can see, as the coordinates are all linear, the resizing factor is the same the UA uses for the image.
The obvious problem is in the case CSS is used to stretch the image. In that case the algorythm should be a bit subtler, resizing the horizontal dimensions according to the width resizing factor and the vertical dimensions according to the height. But the circular areas radius would be a problem, as stretched circles are ellipses.
But I would remind you that if the image has a meaning and therefore readability is important, the author will likely keep the image ratio.
Please consider this issue, it's a matter of presentation and responsive design and I don't think authors have to rely on script for this.

High density images should work fine. The dimensions here are all CSS pixels.
A high density image just has more device pixels for each CSS pixel.

I'm sorry, perhaps I didn't explain my issue enough.
With CSS images can be resized (maybe to adapt them to different device viewports, or just for editorial issues).
But area elements in client-side image maps, i.e. elements inside the <map> element, have their dimensions and position, defined in pixel.
When the image is resized, the <area> elements no longer correspond to effective areas in the image (see example above). So authors need to rely on scripts.
This is my idea. A <map> elements should have a dimensional attribute such as @dimensions (the best option would be another attribute, such as @resize[boolean]. This way, native image dimensions, either from the image file itself or from the dimensional attributes, are passed to the map element). 
When applying the map, the browser should behave this way:
1. find the img element 
2. find the map element associated. If it is designed to be resized dynamically (i.e. if it has the dimensions attribute or the resize attribute, according to the way you think works better), run the following passages:
3. set "initialWidth" and "initialHeight", corresponding to the respective img element attributes or, if missing, to the intrinsic image dimensions.
4. add an event listener on resize event to the image.
5. every time the image is resized, also in the case of the first application of the stylesheet, retrieve the rendered CSS dimensions (storing them in the renderedWidth and renderedHeight attributes).
Now, ideally authors shouldn't use CSS to stretch images. But ideally penguins fly. So, I think that 2 different image resizing factors should be calculated, as follows.
6. calculate 
    widthRatio = Math.round(renderedWidth/initialWidth)
    heightRatio = Math.round(renderedHeight/initialHeight)
    avgRatio = Math.round((widthRatio+heightRatio)/2)
Ratios must be implied for the dimension(s) in the state "auto".
7. for each area element inside the applied area, define the attribute "renderedCoords", initially empty.
8. define the rendered coordinates:
   a. case <area shape="rect" coords="x1 y1 x2 y2"/>
renderedCoords="x1*widthRatio y1*heightRatio x2*widthRatio y2*heightRatio"
   b. case <area shape="poly" coords="xI yI"/> where M is equal to half the number of tokens in the coords value and 1≤I≤M
renderedCoords="xI*widthRatio yI*widthRatio".
   c. case <area shape="circle" coords="xC yC r"/>
This is the most difficult case. The circle could also be turned into an ellipse, but the radius is not defined as horizontal or vertical, so there's no possible guess (it should be assumed that the radius is logically horizontal, but I don't think anyone would do such an assumption). So the average resize factor should be used here (of course if the resize is isotropic, the circle remains a circle and the average is equal to the linear transformation)
renderedCoords="xC*widthRatio yC*heightRatio r*avgRatio"
This way the resulting area will be a new circle, covering most of the circular image area.

Server-side maps cannot be easily made "responsive" and the client maps are an important structural resource in static web pages. It is incredible that maps resizing cannot be achieved via rendering layer.

Ah, yeah, it's true that image maps break down if you dynamically resize the image using CSS (or script).

Browser vendors: do we have vendor interest to make it possible for image maps to work even in the face of varying image dimensions?

Can I talk in stead of vendors? YES we have an interest in that!!! Now that resizable layouts are common use and visual user agents can have really many viewport dimensions and resolution, visual-based elements such as images should be optimized for varying situations.
Client-side image maps can be resized relatively easily. The evidence is provided by several scripts to achieve this, but a standardisation would be required, and a native mechanism would fit better.
On the contrary, server-side image maps are relatively impossible to resize (it would require a submission of the actual viewport, so that the server itself can correct click position). An absurd and senseless choice.

What I mean when asking vendors if they have any interest is do they have interest in implementing it. If we spec it but nobody wants to implement it, the spec is just fiction that gets ignored.

So far it seems that there's not that much interest in image maps in general.

All modern vendors have kept the mechanism for resolving image maps.
Most modern social networks and photo gallery sites use on-photo navigation mechanisms which are now to be solved via transparent block links over the pictures themselves. It would be far easier if a client-side image map could be used, but inserting such map cannot be automatized due to the custom image dimensions (if it's about submitted images) and the fact that such maps cannot adapt to dynamic layouts.
Nobody can implement something that does not exist. There are libraries which modify map dimensions to adapt them to dynamic layouts, so there is authors' interest.

The presence of author interest is not at issue, you are interested and you are an author so that case makes itself.

As you say, it's possible to write libraries to dynamically create image maps. I wonder why more sites, e.g. the social networks you mention, don't use them?

The real question, though, again, is whether browser vendors want to add this feature. They have to keep image maps because of pages that use it, but if they think images maps are a dead-end technology, they might not want to add new features to it. If they think it's something worth working on, then we should add it.

Thank you for your input, but <map> is indeed considered a dead end.